The first, I guess. The problem is that you are technical capable of _decryption_ but gpg does not allow this because for some reasons the key is arbitrary limited to signing. A warning message should be printed in thus a case but decryption should succeed.

Or this (don't allow anon keys for different usage):

diff --git a/g10/pubkey-enc.c b/g10/pubkey-enc.c
index 14cbdbb0f..b8d4059cd 100644
--- a/g10/pubkey-enc.c
+++ b/g10/pubkey-enc.c
@@ -91,9 +91,6 @@ get_session_key (ctrl_t ctrl, struct pubkey_enc_list *list, DEK *dek)
       if (err)
         break;

Do you mean something like this?

It's in master (to be gnupg 2.3).
Enjoy.

The qualitybar has now been removed from 2.2 and master.

Shall we backport this to 2.2 which is our LTS release?

With the recent change the --sender option has an effect on the selection of the User ID used for the key validity check and the TRUST_ status lines:

We already have the option --sender which does what @mgorny requests but only in the TOFU case. I need to revisit the system to see whether we can extend it to WoT and direct key signatures.

GnuTLS seems to have some CMS support; see https://gitlab.com/gnutls/gnutls/-/issues/227 .

I had assumed that GnuPG prioritized the safety of its users over strict adherence to a particular view of a cryptographic protocol

See rG6dc3846d78192e393be73c16c72750734a9174d1 for examples on how to create a cert

Signing using ECDSA does now also work. Tested with 3 in disk keys: nistp256, nistp384 and RSA and verified using gpgsm and Governikus Signer.

Done for master

We do this now always if --auto-issuer-key-retrieve is set. Also backported to 2.2

I back ported @jukivili's changes back to 2.2 which gives a CFB decryption speedup of 25%. I also implemented AEAD _decryption_ in 2.2 to be prepared for mixed 2.2 and 2.3 version use. And AEAD is really fast compared to CFB. Willbe in 2.2.21.

Nope, I was wrong.

Thanks for testing. It's actually an error of generating _unicode_mapping.c, which utf8.c includes.

Thanks for reporting; the code is really new and not yet fully tested.

It seems that the reference to PKCS#5 is correct. It is an issue of how to describe the case of more than 8-byte padding in OpenPGP.

Your example data is malformed, I suppose.

I also don't think that key size obfuscation is useful, after all the preferences of the key demand a certain key size.

Thanks for following up!

No, we always stated that the user id is a mandatory part of OpenPGP keyblocks and that non-compliant keyblocks are rejected. The only exception we made are for revocation signatures where we allow a standalone packet. That exception is done to allow typing in a printed out revocation signature.

To be clear: marking this ticket wontfix means (among other things) that it is the GnuPG project's upstream position that:

With OpenPGP we made user ids mandatory to avoid problems we had with PGP2. I see no reason to revert this.

Nine months have passed since the patches for this problem have been available.

Okay, in 2.2 the output now looks like this:

Won't happen for 2.2

Given that we may move to yet another format in 2.3 I now doubt that we should add such a feature to 2.2.

For reference, here's an error message from openssl smime when it is trying to verify an e-mail message with no embedded certificate at all (despite it knowing about the relevant certificate):

There are likely some bugs in the new code and I also want to do some improvements; see rGb4f1159a5bd7. But things should basically work as before and thus I set this again to testing

i'd be unlikely to ship anything as /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf just because of the mess that admins have to deal with when shipped config files change.

Arggh, gpgconf uses its own option parser so adding the global config file there will require some extra work.

@dkg You might find this interesting. Debian could do stuff in /etc/gnupg/gpg.conf or /etc/gnupg/dirmngr.conf without patching GnuPG to change some defaults.

All done in master with the latest libgpg-error (see T4859). There is always a global configure file in /etc/gnupg (or whatever "gpgconf --list-dirs sysconfdir" prints). The name of the configure file is the same as the user config file (gpg.conf, gpgsm.conf, gpg-agent.conf, ...) but for gpg.conf no versioned config names are used.

Okay, we now have global conf files in master. The extra flags to ignore or force certain options will be added to libgpg-error.

It has now been over 6 months since the patches were available to fix this problem and they have not been adopted upstream.

That sounds like you might have a different issue in mind?

Figuring out the matching user id for a new key signature. Right, --import-options repair-key is the the default and does the same. However, it was also the major cause for the recent trouble with the keyservers because it tried to verify all signatures. repair-keys was made the default (T2236) because it seemed to be nearly for free - which was a false assumption. We should not use this option by default and only consider properly placed signathures as valid. This of course also means that a userid is required.

@werner, i don't understand your last remark. what "required computations" do you think the proposed patches are "moving" from the server to the client?

I see no reason to move required computations from the server to the client.

@werner Could you please give an update on this? Is there any blocker? Is something missing, which prevents merging (and releasing) this?

In 2.2.18, this fix is not included. (partial fix was reverted)

That is actually a GnuPG thing. We originally did it this way to help people remember their passphrase before they start using the key. I agree it is annoying and I would like to remove it too. At the same time we should really think about making no-passphrase the default and require it only with certain compliance settings.

it's been almost a quarter year since my last nudge on this supplied patch. It's not clear to me why it hasn't been merged in master. I'm trying to not be a nag, but:

I thought I close this after the release of 2.2.18.
Anway, it's done, so, closing.

Is this resolved?

On July, 19th, @werner wrote:

You need to wait a bit more.

Or... it could be a feature, not bug, so that failure of -e -r someone can be examined by --locate-keys someone.

Let me clarify the point.

I think that we should apply further change:

diff --git a/g10/getkey.c b/g10/getkey.c
index 077209415..1c337149c 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1369,7 +1369,7 @@ get_best_pubkey_byname (ctrl_t ctrl, enum get_pubkey_modes mode,
     *retctx = NULL;

I found more wrong cases of get_best_pubkey_byname.
For ranking results,
(1) It may return non-encryption primary key as the most relevant key, when its validity is higher.
(2) It may not select encryption primary key even if its creation time is newer.

I also think this makes the most sense.

In my opinion, --locate-key should locate encryption key.

There are some problems with the definition of --locate-key. Further discussion required.

@werner Yes, that sounds great, and would help already a lot, but extending it for card keys would be optimal. Thanks for your work.

In master (to be 2.3) you can add a Label: line into the sub key file of on-disk keys. I use this for quite some time now to show me alabel for my on-disk ssh keys so that I known which one was requested. We can and should extend this to card keys.

I believe that constraint of ret_keyblock != NULL is OK.
Pushing the fix.
Perhaps, backport to 2.2 should be done, too.

If we can assume ret_keyblock != NULL (it is, in current implementation), it can be as simple as:

diff --git a/g10/getkey.c b/g10/getkey.c
index 6802026f6..27bbd354c 100644
--- a/g10/getkey.c
+++ b/g10/getkey.c
@@ -1354,6 +1354,8 @@ get_best_pubkey_byname (ctrl_t ctrl, enum get_pubkey_modes mode,
   int is_mbox = is_valid_mailbox (name);
   int wkd_tried = 0;