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.

Did you remove .gnupg entirely? Secret keys are stored in .gnupg/private-keys-v1.d. If it remained, you didn't import your secret keys.
If it was the case, I'd like to merge this report to T3391: cannot import subkey that was once marked to be on a card.

I reconsidered this. Suppressing such messages with --quiet is oka and will be in 2.2.24.

The "Reliability History" says (in Chinese):

异常代码: c0000005
异常偏移: 0002b6c0

The error code c0000005 is something like SEGV on POSIX, I guess.
It occurred at the address 0002b6c0.

I'm pretty sure what happens, but apparently I haven't been able to explain it clear enough. To reproduce you can do like this:

1. On an old machine having GnuPG version 1, e.g. Red Hat Enterprise 5:
   1. gpg --homedir $PWD/homedir --gen-key
   2. tar cf homedir.tar homedir/pubring.gpg homedir/secring.gpg
2. On a more modern machine having GnuPG version 2, e.g. Red Hat Enterprise 8:
   1. tar xf homedir.tar
   2. touch apa bepa
   3. gpg --homedir $PWD/homedir --sign apa # Does the migration, and signs "apa"
   4. mv homedir homedir.moved # Don't remove, just move
   5. tar xf homedir.tar
   6. gpg --homedir $PWD/homedir --sign bepa # This will fail as explaine in point 5 of the initial description

The inotify thing is only used to detect a deleted homedir and stop the agent. AFAIU your problem is that a migration is triggered again. The migration status is a file ~/.gnupg/.gpg-v21-migrated - are you sure that you have extracted it again?

Applying following SOS-handling, the key can be handled.

diff --git a/g10/parse-packet.c b/g10/parse-packet.c
index 9cb254e24..be7fc6d67 100644
--- a/g10/parse-packet.c
+++ b/g10/parse-packet.c
@@ -188,6 +188,76 @@ mpi_read (iobuf_t inp, unsigned int *ret_nread, int secure)
 }

Note that there is no problem for encrypted key, because it is handled by opaque MPI.

The whole TOFU stuff hash not yet been fully translated because there are conceptional problems with the way the code works.