For ctx->exportPublicKeys returning 0 even when a failure, (with fix of gpg) error handling should be done differently.

Applied and push the change above in rG920154370834: scd,nks: Fix caching keygrip..

Well, I fixed my loopback passphrase provider and the application no longer crashes with a bad passphrase.

Right that description sounds like it is ~20 years old ;-)

Will be fixed with 3.1.14

Works, I've tested with Kleopatra.

relatively new feature

Yes. In the mean time, I'm using a cheap workaround : validate the input passphrase by signing a dummy text before exporting. Not that ugly and can stay for long.

For the first issue, I pushed the change in rGc3a20c88fb30: scd: Fix an error return for READKEY..

Fixed in rG006944b856ee: scd,nks: Fix SEGV for learn for older card..

Great. Please apply the patch.

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