Fixed in 348da58fe0c3656e6177c98fef6b4c4331326c8e.

Well, if you ask *this* nicely, then I will most certainly get *right* to it.

You know what I find annoying? Me writing tests, and then on the first sight of
trouble, we back them out or disable them.

Then please fix that. TBH I find it annoying that you did not check that your
commit actually solves the problem. I mean just using the "stable" branch would
have been enough to see that.

It's important that GPGME builds / runs against all versions of GnuPG and most
distros treat test failures as build failures. Now 1.9 will again need patches
or the python bindings disabled which is creating unnecessary work downstream
which already had enough work with the recent releases.

Indeed. We did not address the issues at all, we decided to skip all tests and
some fell through the cracks.

Unfortunately 1.9.0 doesn't address fully the issues:

[ 108s] Traceback (most recent call last):
[ 108s] File "./t-protocol-assuan.py", line 27, in <module>
[ 108s] err = c.assuan_transact('nop')
[ 108s] File "/home/abuild/rpmbuild/BUILD/gpgme-1.9.0/lang/python/python2.7-gpg/build/lib.linux-
x86_64-2.7/gpg/core.py", line 790, in assuan_transact
[ 108s] errorcheck(err)
[ 108s] File "/home/abuild/rpmbuild/BUILD/gpgme-1.9.0/lang/python/python2.7-gpg/build/lib.linux-
x86_64-2.7/gpg/errors.py", line 62, in errorcheck
[ 108s] raise GPGMEError(retval, extradata)
[ 108s] gpg.errors.GPGMEError: GPGME: IPC connect call failed

Two tests fail.

gnupg2-2.1.19-1.fc27.x86_64
libgpg-error-1.27-1.fc27.x86_64
libassuan-2.4.3-2.fc26.x86_64

Which version of _GnUPG_ are you using?

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.