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.

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

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.

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.

Yes, it is due to a backport from master: rG1049f06c6d2e: scd:openpgp: Allow keygrip to be used to reference a key
Fixed in rG84020385be19: scd:openpgp: Public keys should be available for check_keyidstr..

I looked the gpg-agent.log, it indeed suggested the problem fixed in rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN., which is included in 2.2.24.

Building and installing 2.2.24 at least made it not crash, the very least it's an improvement in that respect.

You have multiple readers and using PC/SC by specifying reader-port.
We fixed in master by T4998: scdaemon: PC/SC "No such device" without reader-port, and I didn't know similar fixes should be backported.
I will soon.

The problem seems to have returned in 2.2.24.

Thanks again for your report.

I'm still having problems with 2.2.24. Now the card removal is detected correctly, but the initialization fails.

We had some card related regressions in 2.2.23. I would appreciate if you could first test again with 2.2.24 which was released yesterday.

Resetting priority to normal for re-evaluation

Re-opening. Now trying to generate new keys fails with a "Wrong card" error.

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.

Note that you actually run 30 independent processes with gpg 1.4 but with gpg-agent there is just one process to handle the private key operations (decrypt). To utilize more cores you need to setup several GNUPGHOME with the same private keys.

I think that it is not gpg-agent but pinentry which causes millions of futex syscall errors.
For interactive use case, pinentry may be the point of contention.
I might be wrong if your key is not protected by passphrase.

Indeed, I think this might be a driver problem.

I don't see any problems in your PC/SC log, at all. If it is the failure of vendor's driver, we actually have no way to fix.

I have been able to resolve the problem by writing:

Sorry, I do not understand what kind of bug you are trying to report. it seems that you have a question about some software and you assume this is gpg4win. "invalid pocket" is however not an error any of our software emits.

Note that Kleopatra verifies the currently active card before starting the generation of new keys. This prevents the destruction of keys on the wrong card.

I am trying to solve this problem since one month

Thanks for your report, but your excerpt is irrelevant.

Push the change.

Thank you.

This is a regression of the multi-card, multi-app support in Kleopatra, i.e. T5066. Generating OpenPGP keys fails because the PIV app is active on the card and the code does not switch to the OpenPGP app. (It also does not switch to the correct card if multiple cards are inserted which could result in the destruction of keys on the wrong card.)

Works for me. Also with a gpg.conf-2 file. Do you use a /etc/gnupg/gpg.conf ?

For 2.2, rG61aea64b3c17: scd: Fix the use case of verify_chv2 by CHECKPIN. fixed this problem.

Fixed in master.
(confirmation interaction is also fixed.)

Need another patch to export it:

diff --git a/g10/export.c b/g10/export.c
index 8dd0b07d7..339424e19 100644
--- a/g10/export.c
+++ b/g10/export.c
@@ -627,6 +627,57 @@ canon_pk_algo (enum gcry_pk_algos algo)
 }

It's fixed in master by T3465: --pinentry-mode loopback with --delete-secret-keys, with new confirmation interaction.
For 2.2, you can use --batch and --yes, see T4667: "gpg: deleting secret key failed: No pinentry" when in --batch mode with --pinentry=loopback.