Thank you @dkg for the analysis. Unfortunately, the certificate cache is hashed by SHA-1 FPR, so, I think that it is a bit difficult to implement moving certs "front" / "back".

I think that for GnuPG 2.3.7 or later, you can add "Prompt: no" in your private key, which helps your interactions.
https://dev.gnupg.org/source/gnupg/browse/master/agent/keyformat.txt$138?as=source&blame=off

Fixed in 1.2.1.

Fixed in 1.2.1.

Fixed in 1.2.1.

Thanks for the followup about R3, @mpilgrem! Looking at your logs in more details, and the source code for find_cert_bysubject in dirmngr/certcache.c, i think i see what the issue is. It's slightly more subtle than not terminating early if a known trusted root can validate a truncated chain.

@mpilgrem, i'm glad that removing the DST Root CA X3 from your windows control panel worked for you, but it still doesn't seem to be a reasonable fix from a GnuPG user perspective

Thanks for the information.
As a follow-up: Is it possible to tell gpg-agent to

• not ask to insert a missing smartcard (and behave as if cancel had been clicked; after which the next private key is used)
• but to ask for the pin, if the smartcard happens to be inserted?

At least, pinentry-qt offers this functionality since 1.2.0 (see T5517: Improvements for symmetric encryption).

Isn't this (mostly?) done? See T5517: Improvements for symmetric encryption.

pinentry 1.2.1 has been released today

I added this option on 2005-07-19 and iirc this was planned for the FSFE's rig to produce their membership cards. I kept that option in 2.0 for backward compatibility but it does not make any sense because its gpg-agent's duty to ask for cards - gpg does not known about it.

The PKCS#12 import was a late add-on because I consider P#12 to be a nasty and insecure format. Unfortunately it survived and is now the mainly used interchange format. Eventually we need to improve things here. However, ppl should use smartcards for S/MIME.

We have a cancel button and an cancel-all button (Window close button). The former skips the current key the latter should cancel the entire decryption process.

Needs to be forward ported to master

I'll flag it for re-testing with the next version.

The (): is the result of Formatting::formatForComboBox(d->key()) which has just been changed to Formatting::formatForComboBox(target) to fix T6154: Kleopatra: Assert in CertifyCertificateCommand after setting ownertrust of key. I think this issue here is just another symptom of the same bug as in T6154: Kleopatra: Assert in CertifyCertificateCommand after setting ownertrust of key. You were just quick enough to avoid the assert.

Looks like this option has been merged 16 years ago from gpg 1.4.3. My guess is that it was never used in gpg 2.x.

For the original issue I'd prefer to silence the error/warning with -Wno-narrowing because I think it's a non-issue. Or does changing the enum declarations to enum : unsigned int make clang happy?

If you use an IP address there is no server name and thus a) TLS can't check the name and b) virtual servers won't work. But as you stated this is not the problem: With rGb231959728a0056 (T2924) https is handled in another way than hkps.
Now, that change was only applied to KS_GET and not to KS_SEARCH. This is kind of correct but shows this surprising behaviour: For the preferred keyserver we really want to do a plain fetch and don't have all the hkp ip/name mapping we do.

For gpgme (as for the other GnuPG libraries) we use the good old mailing list based process for contributing patches. See doc/HACKING for details. In particular, we'll need a signed DCO from you.

Should be fixed.

also, in the recipient tab the "encrypt with passphrase" option is at the very bottom and so far away from the other options that it is easily overlooked, if the window is fullsized.

Turns out the error happened because on Windows I tested with the IP address and not the name. With gpg-connect-agent --dirmngr I get:

Oh, more testing shows that this works on Linux. strange.

Doing the same thing on my second PC, I can be more precise:

The delays are due to /usr/sbin/laptop_mode from the laptop-mode-tools package.

Inserting as well as removal is detected on my machine always only after 25 seconds

Right, this is only for the OPENPGP cards. Meanwhile we have
a way to get information on the supported algorithms. For example:

Yes, this is with Clang. I am working on getting it to compile on Windows with clang-cl, using vcpkg, with success. I have several patches to fix the issues that clang detected, and so I wonder if I should create a Task to discuss them all?

This (old) task only concerns OpenPGP smart cards resp. the OpenPGP card app, right? Because for PIV ECC has always been offered since PIV is supported. And for other card apps we do not even support generating keys AFAIK.

I'll reopen this ticket here, since the underlying issue is not quite resolved yet as @dkg helpfully outlined above.

scdaemon should return this information together with other information about the smart card or the key slot.

@werner please write a list for which manufacturer and version kleopatra should offer which curves.

g++: error: unrecognized command-line option '-Wc++11-narrowing'; did you mean '-Wno-narrowing'?

How did you get this error? I don't even see a warning for this when building gpgme with g++ (SUSE Linux) 12.1.1 20220812.

I wrote a simple testusb.c if monitoring USB devices works:

#include <stdlib.h>
#include <libusb.h>
#include <poll.h>
#include <stdio.h>

Thank you dkg. I am new to 'certificates' generally - and a little knowledge is a dangerous thing - but this is what I did:

@mpilgrem: in the meantime, for connecting to keys.openpgp.org, which *has* cleaned up its certificate chain, you might also want to try killing your dirmngr process, and/or cleaning up the data in .gnupg/dirmngr-cache.d/.

Basically, the website in question (e.g. https://openpgpkey.gnupg.org/, which exhibits this problem) serves up three certificates:

In T6136#161943, @ikloecker wrote:

This looks like a good approach, but I think stripping the standard paths needs to be deferred until later, because, if PKG_CONFIG_SYSROOT_DIR is set, then the library search paths are prefixed with $PKG_CONFIG_SYSROOT_DIR, and then the prefixed standard paths probably shouldn't be stripped.

Sure. I think we can do this after 3.1.24. I don't want to have additional string changes now as we have translation at 100%

Fix issues found while testing with NVDA.