Hi! On Thu, 2025-03-20 at 22:00:04 +0100, Christoph Biedl wrote: > Being one of those on the list, I'm even more confused than I'd be about > this anyway.
Ok, let me try to clarify, then! > So those people you listed: > > * Did they something wrong (although certainly with best intentions)? I don't think so, or at least if they did something explicitly, probably not wrong at the time they did it. > * Are they just victim of the circumstances (versions of the software, > unhandy configuration, ...)? I think this is mostly due to GnuPG having had non-ideal defaults in the past, that required for people to follow online guides to tune their configurations to be able to generate safe keys at the time. And it still having insecure defaults in some aspects right now. > * Is this a problem if apparently everything went fine in the many past > years? I think there's widespread agreement that using SHA-1 in a security context is not wise at this point in time. The problem is that when using GnuPG this is sometimes invisible unless asked for explicitly. There's been collective efforts to remove that from usage. For example dpkg-source and dpkg-buildpackage have considered SHA-1 and RIPEMD160 as weak digests in signatures since 1.21.0 (2021-12), apt had done the same for repo signatures since 1.2.8 (2016-03) but I don't see it ever passed --weak-digest to gpgv so I think the reported problems here would have slipped in, but it should refuse them now that it has switched to use sqv since 2.9.19 (2024-12), and the Debian archive too for the .dsc and .changes signatures themselves since <https://lists.debian.org/debian-devel-announce/2017/02/msg00007.html>, and while I had the notion that we had SHA-1 usage in the keyring, I assumed that was mostly for inactive people. I was surprised to realize that the archive was still allowing uploads for these keys, that's why I also filed #1100894 for ftp.debian.org, and #1100734 for debian-keyring. But in any case, as I mentioned on my original mail, these should already be problematic right now. For instance (and not meaning to pick on you, just as a practical hopefully relatable example) when replying to this email, your signatures failed to verify for me with mutt + sq integration [M], with: ,--- [-- PGP output follows (current time: Thu Mar 20 23:10:14 2025) --] Error: 597308FBBDBA035D8C7C95DDC42C58EB591492FD is not valid according to the current policy, ignoring because: No binding signature at time 2025-03-20T22:10:14Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2023-02-01T00:00:00Z Signing key on 597308FBBDBA035D8C7C95DDC42C58EB591492FD is not bound: Error: No binding signature at time 2025-03-20T21:00:00Z because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance because: SHA1 is not considered secure since 2023-02-01T00:00:00Z 0 authenticated signatures, 1 bad key. Error: Verification failed: could not authenticate any signatures [-- End of PGP output --] `--- [M] https://wiki.debian.org/OpenPGP/Sequoia#mutt Or for a recent upload for src:file, the signatures for the source package also fail to verify: ,--- $ apt source --download-only file […] # With sq as OpenPGP backend $ dpkg-source --require-valid-signature -x file_5.46-2.dsc No acceptable signatures found dpkg-source: error: cannot verify inline signature for ./file_5.46-2.dsc: no acceptable signature found # With gpg-g10code as OpenPGP backend $ dpkg-source --require-valid-signature -x file_5.46-2.dsc gpg: Signature made Thu Mar 13 19:46:00 2025 UTC gpg: using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD gpg: Can't check signature: No public key dpkg-source: error: cannot verify inline signature for ./file_5.46-2.dsc: no acceptable signature found $ k=/usr/share/keyrings/debian-keyring.gpg $ gpgv-g10code --keyring $k file_5.46-2.dsc gpgv: Signature made Thu Mar 13 20:46:00 2025 CET gpgv: using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD gpgv: Good signature from "Christoph Biedl (Debian) <debian.a...@manchmal.in-ulm.de>" $ echo $? 0 $ gpgv-g10code --keyring $k --weak-digest SHA1 file_5.46-2.dsc gpgv: Signature made Thu Mar 13 20:46:00 2025 CET gpgv: using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD gpgv: Note: signatures using the SHA1 algorithm are rejected gpgv: Can't check signature: No public key $ echo $? 2 $ gpgv-sq --keyring $k file_5.46-2.dsc >/dev/null gpgv: Signature made Thu Mar 13 20:46:00 2025 +01:00 gpgv: using RSA key 597308FBBDBA035D8C7C95DDC42C58EB591492FD gpgv: Can't check signature: Bad public key $ echo $? 2 `--- Notice that dpkg-source already fails to verify (and it does regardless of the OpenPGP backend it will use, as it has passed --weak-digest SHA1 to gpg since 1.21.0). And gpgv from GnuPG does not consider SHA-1 weak by default, while gpgv from Sequoia does. > * Is there a problem to come? I'd expect signatures from these keys will eventually also be rejected on the archive side and a campaign will be done by the Keyring Maintainers (as had been done in the past for weak DSA or <1024-bit keys and similar). But the how and when is up those teams. > * Is there something they should do about it? See my original mail about the recipe and links on how to fix these problems. Once fixed they should send the fixed certificates to the keyring.debian.org keyserver. If they want to keep using GnuPG, they should probably check whether their configuration file includes any option forcing SHA-1 or other weak digests, or key lengths, etc. > * Is there something they can do about it? Unless perhaps creating > a new key? See previous point, but no, there should be no need to generate a new key. (This should be similar to refreshing ones key expiration for example.) > * Are measures in place newly generated keys will not suffer from > these problems? All the SOP implementations (sqop, rsop, gosop, pgpainless-cli) should have secure defaults, Sequoia-PGP (sq) as well, GnuPG 2.x (gnupg, gpg) should have also good defaults for new keys (but not for other things as seen above, and might have unsafe old config options set). I'm not sure about GnuPG 1.x (gnupg1), but out of caution I'd assume it does not have good defaults. I've not checked but I'd assume rnp also has good defaults. I'm happy to try to address anything that seems unclear, or get someone else who might be able to answer! And as Holger suggested elsewhere, we can probably also create a FAQ on the wiki with some of this to point to people. Thanks, Guillem
