I realized that some AEAD cipher (including GCM) allows arbitrary length for IV.
But it's not good for the API of setup_geniv and geniv.

rejecting an intermediate certificate too.

Pushed the change of mine to master, since I can confirm that it results validate_cert_chain working better, because of put_cert's rejecting an intermediate certificate too.

You get this error because the key has been created in gnupg mode (and not in de-vs) and thus it has these preferences.

That's a fair point, cheers!

In T6161#162306, @ikloecker wrote:

I'm not sure I understand. If you don't want pinentries depending on libX11, then simply disable those pinentries with --disable-pinentry-qt5, etc. For Wayland it may make sense to allow disabling it.

I'm not sure I understand. If you don't want pinentries depending on libX11, then simply disable those pinentries with --disable-pinentry-qt5, etc. For Wayland it may make sense to allow disabling it.

Let's turn this into a feature request.

I think we can close this one. Note also that we now have --no-user-trustlist and --sys-trustlist-name. in 2.2.37 and 2.3.7 which allows to entirely ignore the user trustlist and to define a global one..

I pushed the change with documentation.

I pushed the changes. It also cares about the case for --cflags.

@dkg: Thanks for the detailed description of the problem.

@orbea Thank you for your suggestions.

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.