Ping. Is this patch ok? I'm pretty sure it is and I've included it in Gpg4win but before I can push the default_pubkey_algo respecting change to Kleopatra I need this to work in GPGME.

I've updated to gpgme-1.8.0 and tried again.
I have one mail that I'll call "bad" which gives me in mutt:

This works fine with GPGME 1.9.0 and master.

Patch now fixes the problem in gpgme

I guess I should do this.

Ah right, that is bad...

I just tried this, but this doesn't disable the detection, and if that fails, the configure script stops:

checking for swig... /usr/pkg/bin/swig
checking for a Python interpreter with version >= 2.7... python2.7
checking for python2.7... /usr/pkg/bin/python2.7
checking for python2.7 version... 2.7
checking for python2.7 platform... netbsd7
checking for python2.7 script directory... ${prefix}/lib/python2.7/site-packages
checking for python2.7 extension module directory... ${exec_prefix}/lib/python2.7/site-packages
checking for python2.7... (cached) /usr/pkg/bin/python2.7
checking for a version of Python >= '2.1.0'... yes
checking for the distutils Python package... yes
checking for Python include path... -I/usr/pkg/include/python2.7
checking for Python library path... -L/usr/pkg/lib -lpython2.7
checking for Python site-packages path... /usr/pkg/lib/python2.7/site-packages
checking python extra libraries... -lutil -lm
checking python extra linking flags... -Wl,--export-dynamic
checking consistency of all components of python development environment... no
configure: WARNING:
  Could not link test program to Python. Maybe the main Python library has been
  installed in some non-standard library path. If so, pass it to configure,
  via the LDFLAGS environment variable.
  Example: ./configure LDFLAGS="-L/usr/non-standard-path/python/lib"
  ============================================================================
   You probably have to install the development version of the Python package
   for your distribution.  The exact name of this package varies among them.
  ============================================================================

Sure there is. Do ../configure --enable-languages= to build no bindings at all.

Oh, to make it clear - I was testing the pkgsrc version with the additional patches used by pkgsrc, see http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/security/gpgme/patches/

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