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.

In T6369#167642, @werner wrote:

The context cloning should not be that expensive compared to invoking gpg. Thus let us first see how to speed up this in the common case.

That's what I was initially trying to do, but then I saw https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=blob;f=src/keylist.c;h=1c01bd42b8497932d218e4d525794ed98e712bf5;hb=HEAD#l1362 and I wasn't sure if I needed to copy that logic to avoid introducing any regressions.

If you got a limited list of, say, fingerprints, you should put them into an array and use gpgme_op_keylist_ext_start tolist only those keys. This will be much faster.

In T6369#167649, @ikloecker wrote:

Finally, what's your use case? gpgme_get_key() is meant to be used for getting individual keys. It's not meant to be used to get 1000 keys in a loop.

If you mean gcc optimization flags, then yes.

Finally, what's your use case? gpgme_get_key() is meant to be used for getting individual keys. It's not meant to be used to get 1000 keys in a loop.

Moreover, if you have performance problems on Windows, then it's not the best idea to strace the code on Linux.

Just asking the obvious: You are using an optimized release build for your benchmarks, right?

Benchmark script:

yeah, I'd guess it's creating a new gpg instance with it. strace shows extra clone/pipe/read/fcntl syscalls with the new context.

The context cloning should not be that expensive compared to invoking gpg. Thus let us first see how to speed up this in the common case.

Output of --show-configs should also be added as a button or directly visible when the selftest of Kleopatra fails.

Okay. So the problems with "file type 1" seem to come from git using hardlinks and tar storing them as hardlinks, but gpgtar ignores them on --decrypt. This would also explain the larger size of the archives if gpgtar stores the hardlinked files multiple times in the archive. Take home message: Don't gpgtar your git repo!

Running gpgtar directly only gives slightly better results. The following

GNUPGHOME=~/xxxx gpgtar --batch --status-fd 2 --gpg-args --enable-progress-filter --encrypt --gpg-args --always-trust -r D5E17E5ABC11F4CD060E02D41DD0D4BAF77BE140 -r C02C4012C09B2AE33921CF87577E88AC284DC575 --output - --directory /xxxx src >src-gpgtar.tar.gpg 2>src-gpgtar.log

took about 31.1 seconds.

These are USTAR types:

For testing the old version, did you use GNU Tar with Kleopatra or changed the configuration to use gpgtar?