More specifically, in the situation of multiple calls, ->getPassphrase is called multiple times, and it should return newly allocated "char *" object each time, because it is released each time (in lower layer).

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.

Okay, I now got such a patch:

I found a good enough solution: I changed the code to compute the OpenPGP s/n from the Yubikey s/n right after a Yubikey has been detected. Later, and if OpenPGP enabled on the YK, the S/N is already there but we use the S/N from the 0x4f DO. That is needed because we can't compute the OpenPGP version number ahead and use 0.0 in the S/N.

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).

Please use shorter password.
For gpgsm, maximum is 31 chars.

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.

Stable now and works as expected. Thank you!

Killing the daemon using gpgconf is fine if you are aware you need to do it. We weren't, and I suspect few other users would be either.

Released on 2020-11-18

Note that if you run into problems with a smartcard you should run "gpg --card-status" once. GUI frontends usually do that and this is the reason why this regression was not detected. Will be fixed in 2.2.25 (T5140).

Removing 2.2 tag because it has been fixed in one of the last releases.

Its done for 2.2 thus changing the tag.

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).

As @dkg noted T4592 is a duplicate of this and given that we have a mitigation in place we can also close this (older) bug.

Thanks.

Before step 2.d you should stop gpg-agent and other daemon

In T5151#139330, @ikloecker wrote:

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

This was fixed in 2.2.24 with commit rG7f765a98fd662

If you want to debug this, I suggest to use a logging socket. Put into all gpg-agent.conf files these lines:

In T5151#139332, @ikloecker wrote:

Can you try if using the overload

As for renaming "Change Reset Code" to "Set Reset Code", what about "Change PIN" and "Change Admin PIN"? Should they also be renamed? If not, why not? Is there no default reset code? Is there a way to find out whether the reset code has already been set (in which case "change" would be more appropriate than "set")?

You write

This does not work.

Can you be more specific? What doesn't work? Which OS, which version of Kleopatra, what smartcard are you using?

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.

I though about this too but we need to take care about the logging functions of Libgcrypt which are intertwined with nPth (clamp function of libgpg-error).

The same problem occurs for NKS (v3) cards where the keys also do not have a keytime.

The above workaround may not be necessary because another code path sets the algorithm string as seen in

$ gpg-connect-agent "SCD READKEY --info -- NKS-NKS3.4531" /bye
S KEYPAIRINFO 39400430E38BB96F105B740A7119FE113578B59D NKS-NKS3.4531 - - rsa2048

The following patch fixes the crash:

diff --git a/scd/app-nks.c b/scd/app-nks.c
index 47be7cd85..4d925dccd 100644
--- a/scd/app-nks.c
+++ b/scd/app-nks.c
@@ -871,7 +871,7 @@ do_learn_status_core (app_t app, ctrl_t ctrl, unsigned int flags,
                                 id_buf, strlen (id_buf),
                                 usagebuf, strlen (usagebuf),
                                 "-", (size_t)1,
-                                algostr, strlen (algostr),
+                                algostr, algostr ? strlen (algostr) : (size_t)0,
                                 NULL, (size_t)0);
             }
           xfree (algostr);

Thanks, I was wrong.

Right, our installation really needs an update. It is not gnupg.org mail but just the mails from phabricator - which unfortunately does not use our standard mail system

Adding [algostr] in g10/call-agent.c is correct, but there is no [fprtime] (resp. it's already listed in the format as [keytime]).

How about distinguishing CARDNO and application specific SERIALNO?