Quite frankly, if a third party application calls gpg with anything other than fingerprints to specify keys it's asking for trouble. I have changed KMail from using user IDs to using fingerprints when calling gpg more than 20 years ago.

Sorry, Werner, but I have to disagree on this. Specifying them by fingerprint only works if you have a specific field for the key (including the case where you are just it on the config file).

I'm attaching a proposed patch. We should decide whether this is the correct encoding to use for SHAKE128 and SHAKE256, because they are variable-length output functions and there is an alternative encoding that has a field for the length, which is likely better suited, but currently not really well supported by libgcrypt (since this would be dynamic content in the ASN.1 encoding).

Instead of tweaking this and risk a regression for some users I added a suggested to the man page to use a fingerprint.

Unfortunately there are real world applications which make use of this option in special environments. Thus we can't remove it. I improved the warning in the man page.

There will be a 2.2.43 soonish. Thanks for the patch.

I would have expected an error message right after

Thanks. Applied to 2.4 will eventually be merged into master.

Do note there could be subkeys as well.

I recently stumbled upon this as well.

I agree. Any automatic use of the embedded filename will be potentially problematic security-wise. The only safe use is probably as a value in an interactive dialog, and even then, only if the user doesn't accept a dangerous value.

This was reported again 3 years later as T4704, and finally fixed in gnupg-2.4.4, released last week.

The patch supplied here should apply to STABLE-BRANCH-2-4, but it should also be easy enough to backport to STABLE-BRANCH-2-2 and STABLE-BRANCH-1-4. For GnuPG master, i recommend actually removing the option.

Unfortunately I have deleted the .p12 with the CA chain, and I don't know how I've generated it. It also contained my production certificates so, kinda sensitive to upload here.

Okay, I push the change for the extended salt size. Regarding the import of CA certificates, I have not seen any problems. In fact it is pretty common. Did you test with with 2.4.4. A test file would be helpful.

Ok, I have tried again the series of workarounds that I initially posted on the main description, and I managed to fix it by striping the CA certificates. So the current issues here are:

• Allocated salt is too small. https://dev.gnupg.org/T6757#182217 fixes for now
• Cannot import a .p12 that includes CA certificates as well

This is still an issue.

Verified in ntbtls-0.3.2.

Fixed by changing server as noted above.

Thanks for all the help @gniibe.

It should not be removed as I believe it is required to be compliant: