My excuse: Please note that the support of exporting secret keys by GPGME are relatively new feature (see {T5046) and the fix rM3382ecb17eb5: core: Support exporting secret keys.). The fix of rM53ac732bae46: core: Call _gpgme_passphrase_status_handler when exporting keys. is a part of the support.
I think that we need more fixes for gpg/gpgme to be fully working well.

In T5151#139410, @gniibe wrote:

when passphrase is wrong, the passphrase callback is called more than one time (one for primary key, and another for a subkey, more if there are more subkeys).

Currently, gpg doesn't report any errors to status line for exporting secret keys. If needed, a patch like this is needed:

Chasing this bug, I pushed a change: rM53ac732bae46: core: Call _gpgme_passphrase_status_handler when exporting keys.

In T5151#139353, @nmset wrote:

Using Context::setExpire(), expiry time of keys and subkeys can be changed in a predictable way, with good and bad passphrase (fails with error of course).

In T5151#139330, @ikloecker wrote:

I highly recommend to use the new ChangeExpiryJob instead of the fragile (and apparently buggy) edit interactor.

In T5151#139332, @ikloecker wrote:

Can you try if using the overload

Can you try if using the overload

Error Context::exportPublicKeys(const char *patterns[], Data &keyData, unsigned int flags)

which takes an array of patterns instead of a single pattern also crashes?

Unless you need some special features of GpgSetExpiryTimeEditInteractor or you have to support gpgme <1.15, I highly recommend to use the new ChangeExpiryJob instead of the fragile (and apparently buggy) edit interactor.

Fixed. Workaround for gpgme 1.15 (and earlier) implemented in Kleopatra: Do not call setRemark() with an empty QString.

I think Kleopatra is affected. It calls setRemark() on the job unconditionally with the text from the widget, and I'm pretty sure that this text is empty but not a null QString, if the user doesn't enter a remark.

Ingo, can you please check? I guess we are not affected because Kleo already checks for an empty string. But dkg's suggestion sounds good to me.

Thanks for your report, but your excerpt is irrelevant.

Push the change.

Thank you.

Pushed the change.

IIUC, fix can be like this:

diff --git a/lang/python/src/core.py b/lang/python/src/core.py
index 996c3b0f..646bbc60 100644
--- a/lang/python/src/core.py
+++ b/lang/python/src/core.py
@@ -147,7 +147,12 @@ class GpgmeWrapper(object):
                     gpgme.gpg_raise_callback_exception(slf)
                 return result

Good catch. Thank you.

The following patch make it work:

FWIW, here an example of warnings we use. Yes it starts with -Wall but there are a couple of more specific warnings and at a few places we even use pragmas to disable warnings. And it depends on the compiler version used.

-Wall is not a good idea in general because it is too unspecific. This is why we have a list of useful warning and >warnings we ignore with gcc.

-Wall is not a good idea in general because it is too unspecific. This is why we have a list of useful warning and warnings we ignore with gcc.

I found the bug by compiling the package with C/C++ compiler clang and flag -Wall.

Fixed in gnupg and gpgme. it is not serious because that is just a failsafe check; libksba creates these strings and it does it correctly.

We have the same flaw in gnupg.

Fixed.

Taking: Still does not work although now --quick-set-expire is used by gpgme.

We won't do such a interface now.

Thanks. rMdb82e99 resolved this.

I just ran the test suite ~10 Times with -j48 on a 12 core machine and cannot reproduce this at all with GnuPG-2.2.21 and gpgme-1.14.0 so I tend to put this on resolved, otherwise this is a candidate for an issue that will be indefinetly in the tracker which we cannot reproduce or analyze further.

The t-json failure is: T4820

Thanks, I've applied this with an explicit include to <cstdlib> it was not required on Linux and Windows but I think it's better not to rely on internal libc++ include chains.

Thanks for your report.

According to OS X 10.9 man pages for getenv(3) (10.9 is what I have available), the source file editinteractor.cpp should include <stdlib.h>. Since its a c++ source file, I believe the include of interest is <cstdlib>. The man page also says the link library is -lc.

Phabricator allows it again to upload patches. It's D507

C++ interface is also availabale in 1.14.0 (see rM690d967196d9).

No info received

I am not any longer interested to see the real cause; eventually we will replace it anyway with a modern CreateProcess.

Reconsidering this: Running the test suite with gpg1 is not a proper use case. gpg1 may be installed in addition to gpg but it should never be used on a build machine solely.

As of today we don't want to maintain another binding; see T3395

The Python bindings are troublesome enough; as of today we don't want to maintain a Perl module.

No info received in3 years.

Has already been fixed with T4061.

C part done; C++ interface is not yet done.

Today when I've been trying with -j48 test suite was locked and was not able to finish.
When I've presses ctrol-c I found:

PASS: t-eventloop
Decrypt B 0
Encrypt A 0
Decrypt B 1
Encrypt A 1
Decrypt B 2
Encrypt A 2
Decrypt B 3
Encrypt A 3
Decrypt B 4
Decrypt B 5
Encrypt A 4
Decrypt B 6
Encrypt A 5
Decrypt B 7
Encrypt A 6
Decrypt B 8
Encrypt A 7
Decrypt B 9
Encrypt A 8
Decrypt B 10
Encrypt A 9
Decrypt B 11
Encrypt A 10
Decrypt B 12
Encrypt A 11
Decrypt B 13
Encrypt A 12
Decrypt B 14
Encrypt A 13
Decrypt B 15
Encrypt A 14
Decrypt B 16
Decrypt B 17
Encrypt A 15
Decrypt B 18
Encrypt A 16
Decrypt B 19
Encrypt A 17
Encrypt A 18
Encrypt A 19
PASS: t-thread1
make[4]: *** [Makefile:882: check-TESTS] Interrupt
make[4]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/gpgme-1.13.1/tests/gpg'
[tkloczko@barrel SPECS]$ make[3]: *** [Makefile:1008: check-am] Interrupt
make[2]: *** [Makefile:1010: check] Interrupt
make[1]: *** [Makefile:736: check-recursive] Interrupt
make: *** [Makefile:535: check-recursive] Interrupt
^C

It might be related to T4257 - try with -j4 for now which is what I use for building.
For further investigations we need to enable tracing using

GPGME_DEBUG=8:gpgme.trc  make check

In T4854#135871, @werner wrote:

Sorry, I can't replicate this

Probably the same as T4257

We can't do anything about it except for corner cases which we won't do right now. In case there will be an easy solution to help Debian please re-open this bug.