D416: 991_0001-qt-pass-fmt-to-gpgrt_asprintf.patch

Yep

Andre, can we close this bug?

1.9.0 has been released.

I have noced that you added the C++ interface. Thanks.

I see. Let's get back to this after the release of 1.9

What about gpgme_get_dirinfo ("agent-socket")?

I did not know about that, and that helps a bit, but has the downside that it
uses the GNUPGHOME from the process' environment.

I'm thinking about the following use case. I have created an ephemeral home
directory to contain the results or side-effects of some operation, and now I
want to talk to the agent that serves that particularly home directory. I
cannot use gpgme_get_dirinfo because that uses GNUPGHOME, and I don't want to
change the environment variable because that is a process-global thing and I
don't want to interfere with other threads.

What about

gpgme_get_dirinfo ("agent-socket")

? For testing you can use

GNUPGHOME=/foo/bar gpgme/tests/t-engine-info 2>&1 | grep agent-info

As of 348da58fe0c3656e6177c98fef6b4c4331326c8e all Python tests are skipped with
GnuPG < 2.1.12.

I concur. We should disable the Python tests for gnupg versions < 2.1.12 (which
is about a year old)

I've rebased the patches against 1.8.0 but I still saw 22 failing python tests
with 2.0.26

Master fails for me even harder with 36 tests failing.

The gpg-connect-agent call's fail because --agent-program is not supported. In
master we even have --debug-quick-random which is even more recent (but which we
would also need in random starved environments like build daemons)

My preferred solution at this point would be to just say for 2.0.x the python
tests are unsupported and disabled completely. All the problems are with our
agent setup regarding the test suite and not really with functionality.

Sorry, the test case code is here: https://github.com/rethab/h-
gpgme/blob/master/test/KeyTest.hs#L91

The removeKey function code is here: https://github.com/rethab/h-
gpgme/blob/master/src/Crypto/Gpgme/Key.hs#L64

I hope the attached log helps. The log is a test of this command:
GPGME_DEBUG=9:/home/dmp1ce/Projects/DMSS/h-gpgme/mygpgme.log ./runtests remove_alice_key_prompt

The test is creating a GPG context directory, creating a temporary key and then deleting it. The
log should show me manually confirming to delete the key. I would like the delete prompt to be
suppressed with an automatic deletion of the key. I didn't see any way of suppressing the
confirmation in the documentation here:
https://www.gnupg.org/documentation/manuals/gpgme/Deleting-Keys.html#Deleting-Keys

The code to the test case is here: https://github.com/rethab/h-
gpgme/blob/master/src/Crypto/Gpgme/Key.hs#L64

The test is running the function c'gpgme_op_delete which is a binding to the c function
gpgme_op_delete. Source code for the binding is here: https://github.com/jwiegley/bindings-
dsl/blob/master/bindings-gpgme/src/Bindings/Gpgme.hsc#L534

The log indeed does not match the former gpgme2.trace.

I would try to switch to gpgme 1.8.0 so see whether you can still reproduce the
problem.

Right now it seems to be complaining about an expired key.
(Could be that this is a different error than originally reported because it's
been some time...)

Thanks. So gpgsm is started but terminates before it can actually receive a
command from GPGME. Can you please add

log-file /bar/bar/gpgsm.log
debug 1024
verbose

to ~/.gnupg/gpgsm.conf and run the test again. Please post the log again.

Can you provide a plain C test program to show the effect or, maybe easier a
GPGME trace file running your program?

GPGME_DEBUG=9:gpgme.trace: YOURTESTPGM

See tests/run-genkey --set-primary on how to use it.

commit 421ddd1 implements that for 1.9.0.

I'm maintaining a language binding. https://github.com/rethab/h-gpgme

I've run mutt as suggested on the troublesome email; the resulting log is attached.

To debug this you need to run mutt like this:

GPGME_DEBUG=9:gpgme.trace: mutt

The trace file will be pretty verbose but contains everything GPGME sees from
the engine.

What do you mean by "maintainig a GPGME library"? A language binding or an
implementaion similar to GPGME?

I close this one. An implementation is already in master.

Duplicate of T2819

Done with commit 35023f3.

I modified the patch slighly, added docs and a --from-file to run-keylist.
You may want to add a C== and Qt interface.

Unfortunately I'm unable to test this properly, because the patches can't be
applied properly to 1.8.0 (I need to add them to the package).

FYI this is:
Skip tests if GnuPG is too old.
Use 'gpg-agent --allow-loopback-pinentry' if applicable.

Addressed in e1cf8bab319ba1dea41ba5d711dbb66ffd8e6fd6 and
16b202d9999591b71fb8bb49f6db10ef96d4cbe8.

So this is about the new Python binding.
I would suggest not to build tye python support on systems with the old 2.0.24.
Note that 2.0 will reach EOL in 9 months.

gnupg fixed in dd60e868d2bf649a33dc96e207ffd3b8ae4d35af.

ntbtls fixed in e582e91e47a164816ac074b9078dbed8537601dc.

libgcrypt fixed in 654024081cfa103c87bb163b117ea3568171d408.

libksba fixed in 561d03a008150c201ece22b29c97b24a1f6bf590.

libassuan fixed in b26b73d04bff10852382113ae361ea5726661510.

libgpg-error fixed in 5e51b642f747547c737a7abbc37e65b0f630d188.

Duplicate of T2962

I addressed this for GPGME in 60273e8b2c11d42215a5707bc55e3e0d8f350e07 but
apparently forgot to mention that here.

I'll keep the bug open until I fixed this in all packages.

Thank you very much. Straightforward fix. Applied the patch.

Delegating to our resident C++ expert.

Merged in 9291ebaa4151a1f6c8c0601095ec45809b963383.

Fixed in 6f02133bb07726afa6950e5b4685e75621276e60 by backporting a fix from
gpg-error.

After testing on Windows this problem is not resolved for Windows (I agree that
it's resolved for posix).

The issue there that I see now is not that it's a race between changing the
setting and immediately reading it again but that sometimes the communication
between gpgme and gpgconf fails.

See attached file no-read.txt for some debugging on this. GPGME writes a changed
option to gpgconf but gpgconf does not read it. I've used OutputDebugString and
DbgView to have syncronized debug output over process borders.

Not 100% reproducible but on my test system it fails very often.

FWIW: In GnuPG we have for example this in the configure script

*-*-hpux*)
    if test -z "$GCC" ; then
        CFLAGS="-Ae -D_HPUX_SOURCE $CFLAGS"
    fi

IF it makes things easier we may add a simlar case for macOS. But we need to do
this for many packages, I think.

Fixed in 0e242278dfaa64ce31a45b72f5fa0806a3dba898.

We configure the build with -D_DARWIN_C_SOURCE=900000L on our macOs box. Not
sure if this is the proper thing to do, and/or if we should just always set that
when we build on Darwin in configure.

It seems like indeed it should have been resolved. I have also resolved the issue
by moving the old headers from KDEPIMLibs 4 to a private location, and KF5
projects have apparently been updated to work with gpgme++ installed in
$prefix/include/gpgme++ .

I currently know of no more problems so lets resolve this.