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?

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

{F1982353}

You forgot to add lang/cpp/src/data.h.in

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.