User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

Imported a PGP secret key with two IDs (one subkey) which have been created with GnuPG.

Imported a PGP secret key (two IDs, one subkey) which previously has been exported from Thunderbird (imported with some miraculous asc which worked only once).

Importing binary or asc doesn't seem to make a difference.

Actual results:

The key is not properly imported. It seems that the packets in the asc key file influence the handling of the subkeys.

If I by chance managed the key being imported correctly Thunderbird's export doesn't export the full key in a way that another Thunderbird instance is able to import the key such that on the other instance the same state results.

Expected results:

Import the secret key with all identities and keys properly.

The decision to brew an own (and incomplete) OpenPGP implementation breaks so much which is especially annoying due to the simultaneous dropping of Enigmail.

Hi, could you please attach an output of gpg --list-packets yourkey.asc, removing all the privacy sensitive information if needed?

Seems to be because it uses SHA1, which Thunderbird 91.8.0 no longer accepts (as it's insecure).

Ok, great, thanks! These were the default settings on gnupg though. A warning or import log would be helpful and avoid continuous production of bug reports.

I will test and report/confirm.

Thanks for the (ultra) quick response.

Thanks for the log. Yeah, digest algo = 2 is SHA1, and signatures are created after the cut-off date (Jan, 15 2019).
This link may be helpful: https://unix.stackexchange.com/questions/423109/how-do-i-prevent-gpg-from-including-sha1

Magnus: probably, it would be worth to create some howto article about this situation, I guess you'll receive a number of suchlike tickets. Also it could be worth to add some code to check whether key has SHA1 signatures, created after the cut-off date and display some sort of warning/link to the howto article.

It would indeed be good to show such a warning. Do you know if we have a way of seeing the discarded keys? As I understand it they are now just ignored?

RNP has API for this, but that would require some lines of code:

• for the loaded key, you may iterate over the key/subkey/userid signatures via rnp_key_get_signature_at() (for direct-key and subkey binding signatures) and rnp_uid_get_signature_at() for certifications
• then check whether it is self-signature by comparing primary key id and signer's key id via the rnp_signature_get_keyid() call
• and then via the calls rnp_signature_get_hash_alg() and rnp_signature_get_creation() check whether it uses SHA1 hash algorithm and was created after the timestamp 1547856000.

For anybody who runs into similar issues:

Before generating the key and adding additional IDs I adjusted the default settings within ~/.gnupg/gpg.conf to avoid the weak SHA:

# Note: make sure to update this according to security standards

# Avoid information leaked
no-emit-version
no-comments
export-options export-minimal

# Displays the long format of the ID of the keys and their fingerprints
keyid-format 0xlong
with-fingerprint

# Displays the validity of the keys
list-options show-uid-validity
verify-options show-uid-validity

# Limits the algorithms used
personal-cipher-preferences AES256
personal-digest-preferences SHA512
default-preference-list SHA512 SHA384 SHA256 RIPEMD160 AES256 TWOFISH BLOWFISH ZLIB BZIP2 ZIP Uncompressed

cipher-algo AES256
digest-algo SHA512
cert-digest-algo SHA512
compress-algo ZLIB

disable-cipher-algo 3DES
weak-digest SHA1

s2k-cipher-algo AES256
s2k-digest-algo SHA512
s2k-mode 3
s2k-count 65011712

Using this configuration everything imports neatly.

Now I'm really happy - I was so concerned because I had no indication what has gone wrong. Due to the missing feedback the key import of Thunderbird just felt extremely random and buggy. And having no reliable PGP option for Thunderbird was kind of a shock to me.

I'm a strong advocate of deprecating/prohibiting outdated security algorithms and enforce them. It doesn't help the average user though if he doesn't know what went wrong. So feedback especially when it comes to security is crucial.

Now that it works I really dig the integrated PGP support (apart from not being able to add subkeys). It's long overdue. Actually it's funny that we write 2022 and we're still fiddling with its implementation...

Thanks for all your work!

Addendum: I just tested the export from Thunderbird and also this seems to work with the proper hash, i.e. the packets contained all IDs.

Can confirm that I have this problem too. Tested on 91.8.0 on OSX and Kali Linux

(In reply to cls from comment #4)

These were the default settings on gnupg though.

Can you say which version of gnupg you used?

It seems that gnupg 1.4.x still uses SHA-1 by default, however that version is very old.
Aren't most environments already distributing newer versions?

Since 2009, from version 2.0.13, SHA-1 was no longer used by default:
https://lists.gnupg.org/pipermail/gnupg-announce/2009q3/000294.html

However, as you said, you had a configuration file which asked for SHA-1 by default.
Do you have any idea why you might have had a configuration file with that preference?
I looked at a few systems, but in my experiments I didn't see such a configuration.

This was at least on a stock Ubuntu 18.04. Perhaps it failed even on stock Ubuntu 22.04, but I'm unable to recall it now and would have to test it. So they're not ancient.

On Ubuntu 22.04 it looks like this:

uli@cafe-schlacht:~$ gpg --version
gpg (GnuPG) 2.2.27
libgcrypt 1.9.4

I have no access to the 18.04 device for another two weeks unfortunately. For this info we'd have to extract the info from the packet repository.

(In reply to cls from comment #13)

I have no access to the 18.04 device for another two weeks unfortunately. For this info we'd have to extract the info from the packet repository.

I found a 18.04 system, and it has gnupg 2.2.4 installed. I created a key, and it used SHA-512.

It seems the reason is that you had a non-default configuration file

This is not possible or not the cause since there was no ~/gnupg/...conf file. The contents I posted made up a new file. So something is really weird here.