well, this user made a backup and it went wrong anyway ;-) See T6377

Oh this issue was in the wrong project. Related to T5836

If 3.1.26 only offers RSA algos, then Kleopatra obviously assumes that the smart card only supports RSA and therefore doesn't offer the transfer of Brainpool keys.

I'm sorry, I got a bit confused, it works in Kleopatra on 3.2.0, but not in 3.2.26

Which algorithms are offered when you use "Regenerate Key"? What's the output of gpg -K --with-colon <key_id>?

Thanks. please give a few days.

created ~/.gnupg/gpg-agent.conf containing:

debug ipc,cache
debug-pinentry
log-file socket://

Okay, I see. The commands above are a real reproducer and not standalone examples. Then yes, you should get a pinentry only for the first gpg -d (as long as the keys are still in the cache). I am lacking macOS/homebrew stuff to replicate this. What you can do is to put

Kleopatra simply copies the content of the corresponding *.key file in the private-keys-v1.d folder. If the *.key file contains a shadowed key after issuing a KEYTOCARD --force [...] command followed by a SCD LEARN --force command (note the SCD!), then gpg-agent is to blame.

I may be reading your comment wrong, but the problem here is not multiple pinentry prompts, or multiple gpg-agents present.

Although gpg-agent launching is protected by a file system lock, there is indeed a small race related to the pinentry. The invocation of the pinentries is serialized but if a second pinentry is requested while the first pinentry has not yet returned and put the passphrase into the cache, the second pinentry will be called anyway. Fixing this not easy and should rarely be a problem. The mitigation is to do a dummy decryption to seed the cache or use a custom pinentry.

Hier is a log file from GpgOL (+Code verfolgung)

Works now for gpgme. Thanks!

Works for me with gpgtar (GnuPG) 2.4.1-beta21. I haven't verified this with 2.2.x.

Understood. I appreciate the time you took to analyse the issue. Thanks.

I guess this is the first time such a key was reported. Printing diagnostics would be a bit of work because the code to compute th. expiration time is deep in gpg's guts.

Oh, yes this makes sense in the copy/delete path of utils/path-helper.cpp Kleo::moveDir on Windows src and dest are usually on the same device so this might not have been noticed as much by our users as then it is just a rename.

The first signature is a direct key signature (class 0x1f) and this determines the expiration time. The usual case is to have the expiration time in the user id signatures. Our code does not allow to chnage the expiration time of direct key signature. This is because direct key signature are used by PGP and GnuPG only to add designated revokers. Gpg has no means to create a direct key signature like you have in your key.

Here is the output of gpg --full-timestrings --check-sigs:

pub   rsa3072 2019-05-09 12:08:21 [C] [expired: 2022-05-05 12:08:21]
      ABC96B3B4BAFB57DC45D81B56A48221A903A158B
sig!         6A48221A903A158B 2019-05-09 12:08:21  [self-signature]
uid           [ expired] Linda Mary Patricia Deborah Barbara Susan Maria Nancy <linda@example.org>
sig!3        6A48221A903A158B 2019-05-09 12:08:21  [self-signature]
sub   rsa3072 2019-05-09 12:08:21 [E] [expired: 2022-05-05 12:08:21]
sig!         6A48221A903A158B 2019-05-09 12:08:21  [self-signature]
sub   rsa3072 2019-05-09 12:08:21 [S] [expired: 2022-05-05 12:08:21]
sig!         6A48221A903A158B 2019-05-09 12:08:21  [self-signature]

I have seen that the rule is honoring the exclusions of Microsoft Defender but I do not know if one would need to exclude gpgol.dll or the gpgolconfig.exe / gpg.exe in this case. https://learn.microsoft.com/en-us/microsoft-365/security/defender-endpoint/attack-surface-reduction-rules-reference?view=o365-worldwide#microsoft-defender-antivirus-exclusions-and-asr-rules

With the current development version I get

$ gpg --version
gpg (GnuPG) 2.4.1-beta21
libgcrypt 1.11.0

Indeed. The called function dates back to 2004. We really need to rework this and cache the value - it might be required to take the file_name into account.

This is the file I am repeatedly importing in the sessions from my report. It is one of the keys that seem impossible to unexpire for me.
There is no privacy issue: this belongs to a published test suite and is not used by any human.

@werner I saw the call in _gpgme_set_engine_info at line 452 https://dev.gnupg.org/source/gpgme/browse/master/src/engine.c$452 which I think leads down to _gpgme_get_program_version in version.c which does a spawn and uses no cache.

I had the same suspicion andIchecked the code. afaics all values are taken from a cache (see dirinfo.c). Thus no real overhead.