Guillem Jover wrote:
> Hi!
>
> A recent dupload improvement to switch from its GnuPG based OpenPGP
> verification hook to use the dpkg OpenPGP multi-backend
> implementation, which as a side effect got rid of a very old code path
> that was ignoring some GnuPG verification failures, resurfaced an old
> known problem with OpenPGP certificates with SHA-1 issues in the
> Debian keyrings.
>
> Not all of these issues are equally "bad" from a Debian point of view,
> but all are probably bad for the certificate owners, as it might imply
> that people cannot verify signatures made with those certificates. In
> the Debian context that might mean emails, or signatures on artifacts
> such as .dsc or .changes. Depending on the specific problem those
> might even cause rejects from DAK.
>
> I filed #1100734 against debian-keyring the other day, but to try to
> help people that might get confused by the kind or errors that dupload
> (or dpkg-source --require-valid-signature or dscverify) might be
> emitting (I think dput-ng is strict with its OpenPGP verification and
> should have already been rejecting signatures from those certificates,
> although I think dput might be lenient as dupload used to be and might
> let those through (?)), I've prepared a list of affected certificates
> per keyring, which I'm attaching.
>
> To check for the exact issues you can use the Sequoia certificate
> linter (from the «sq» package) with something like:
>
> $ sq cert lint --cert FINGERPRINT
>
> To fix your certificate it should (in theory) be enough to do:
>
> $ sq cert lint --cert FINGERPRINT --fix | gpg --import
>
> (Given that Sequoia can transparently read from the GnuPG certstore,
> and talk to gpg-agent.)
>
> You might want to check the chapter for that at
> <https://book.sequoia-pgp.org/lint.html>. If you'd prefer to use GnuPG
> to fix your certificate, although in a really more tedious way, you can
> follow these instructions instead:
>
>
> https://lore.kernel.org/keys/fxotnlhsyl2frp54xtguy7ryrucuwselanazixeax3motyyoo3@7vf7ip6gxyvx/T/#u
>
> (I'm also attaching the script I used to generate the lists.)
>
> Thanks,
> Guillem
> Fingerprint: DF3D96EEB3827820F302665C01817AB0AAF6CDAE
> UserID: Robert Edmonds <edmo...@debian.org>
> UserID: Robert Edmonds <edmo...@fsi.io>
> UserID: Robert Edmonds <edmo...@mycre.ws>
Hello,
I'm not sure this analysis is completely correct. As far as I can tell,
you've flagged my key on the basis of "sq cert lint" reporting the
following output:
$ sq cert lint --keyring /usr/share/keyrings/debian-keyring.gpg --cert
01817AB0AAF6CDAE
Certificate 01817AB0AAF6CDAE, key 292C9BB54A4D3CBA uses a SHA-1-protected
binding signature.
Examined 1 certificate.
0 certificates are invalid and were not linted. (GOOD)
1 certificate was linted.
1 of the 1 certificates (100%) has at least one issue. (BAD)
0 of the linted certificates were revoked.
0 of the 0 certificates has revocation certificates that are weaker than
the certificate and should be recreated. (GOOD)
0 of the linted certificates were expired.
1 of the non-revoked linted certificate has at least one non-revoked User
ID:
0 have at least one User ID protected by SHA-1. (GOOD)
0 have all User IDs protected by SHA-1. (GOOD)
1 of the non-revoked linted certificates has at least one non-revoked, live
subkey:
1 has at least one non-revoked, live subkey with a binding signature that
uses SHA-1. (BAD)
0 of the non-revoked linted certificates have at least one non-revoked,
live, signing-capable subkey:
0 certificates have at least one non-revoked, live, signing-capable
subkey with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
Error: 1 certificate have at least one issue
Now, key 292C9BB54A4D3CBA is my encryption subkey, not the main key
01817AB0AAF6CDAE that is used for signing and certifying:
sec rsa4096/01817AB0AAF6CDAE
created: 2013-10-03 expires: never usage: SC
card-no: 0005 00003A89
trust: ultimate validity: ultimate
ssb rsa4096/292C9BB54A4D3CBA
created: 2013-10-03 expires: never usage: E
card-no: 0005 00003A89
Since only the encryption subkey is affected, I do not believe this
problem can affect the signatures on my signed .dsc or .changes files.
Here are the raw PGP packets, from a clean sid chroot with gpg and
debian-keyring installed:
root@7311057f397a:/# gpg --keyring=/usr/share/keyrings/debian-keyring.gpg
--export-options export-minimal --export 01817AB0AAF6CDAE | gpg --list-packets
# off=0 ctb=99 tag=6 hlen=3 plen=525
:public key packet:
version 4, algo 1, created 1380802569, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: 01817AB0AAF6CDAE
# off=528 ctb=b4 tag=13 hlen=2 plen=31
:user ID packet: "Robert Edmonds <edmo...@fsi.io>"
# off=561 ctb=89 tag=2 hlen=3 plen=543
:signature packet: algo 1, keyid 01817AB0AAF6CDAE
version 4, created 1470513048, md5len 0, sigclass 0x30
digest algo 8, begin of digest fb a2
hashed subpkt 2 len 4 (sig created 2016-08-06)
hashed subpkt 29 len 1 (revocation reason 0x20 ())
subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE)
data: [4095 bits]
# off=1107 ctb=b4 tag=13 hlen=2 plen=33
:user ID packet: "Robert Edmonds <edmo...@mycre.ws>"
# off=1142 ctb=89 tag=2 hlen=3 plen=570
:signature packet: algo 1, keyid 01817AB0AAF6CDAE
version 4, created 1408125108, md5len 0, sigclass 0x13
digest algo 8, begin of digest 5e 8d
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
hashed subpkt 25 len 1 (primary user ID)
hashed subpkt 2 len 4 (sig created 2014-08-15)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3)
hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0)
subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE)
data: [4096 bits]
# off=1715 ctb=b4 tag=13 hlen=2 plen=35
:user ID packet: "Robert Edmonds <edmo...@debian.org>"
# off=1752 ctb=89 tag=2 hlen=3 plen=567
:signature packet: algo 1, keyid 01817AB0AAF6CDAE
version 4, created 1408125126, md5len 0, sigclass 0x13
digest algo 8, begin of digest cc 62
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (keyserver preferences: 80)
hashed subpkt 2 len 4 (sig created 2014-08-15)
hashed subpkt 11 len 4 (pref-sym-algos: 9 8 7 3)
hashed subpkt 21 len 4 (pref-hash-algos: 10 9 8 11)
hashed subpkt 22 len 4 (pref-zip-algos: 2 3 1 0)
subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE)
data: [4095 bits]
# off=2322 ctb=b9 tag=14 hlen=3 plen=525
:public sub key packet:
version 4, algo 1, created 1380802569, expires 0
pkey[0]: [4096 bits]
pkey[1]: [17 bits]
keyid: 292C9BB54A4D3CBA
# off=2850 ctb=89 tag=2 hlen=3 plen=543
:signature packet: algo 1, keyid 01817AB0AAF6CDAE
version 4, created 1380802569, md5len 0, sigclass 0x18
digest algo 2, begin of digest 1e e4
hashed subpkt 2 len 4 (sig created 2013-10-03)
hashed subpkt 27 len 1 (key flags: 0C)
subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE)
data: [4095 bits]
If I understand correctly, the last packet is the only one with "digest
algo 2" (SHA-1), which is the self-signature on the encryption subkey
(292C9BB54A4D3CBA). All the other signatures are "digest algo 8"
(SHA-256).
By the way, the hash algorithm numbers are registered here:
https://www.iana.org/assignments/openpgp/openpgp.xhtml#openpgp-hash-algorithms.
I do not see any of the verification failures that you demonstrated
downthread on debian-devel when I try to verify a recent upload of mine:
$ apt source --download-only protobuf-c
NOTICE: 'protobuf-c' packaging is maintained in the 'Git' version control
system at:
https://salsa.debian.org/edmonds/protobuf-c.git
Please use:
git clone https://salsa.debian.org/edmonds/protobuf-c.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 538 kB of source archives.
Get:1 http://deb.debian.org/debian sid/main protobuf-c 1.5.1-1 (dsc) [2,060
B]
Get:2 http://deb.debian.org/debian sid/main protobuf-c 1.5.1-1 (tar) [532
kB]
Get:3 http://deb.debian.org/debian sid/main protobuf-c 1.5.1-1 (diff)
[4,576 B]
Fetched 538 kB in 0s (8,641 kB/s)
Download complete and in download only mode
$ gpgv-sq --keyring /usr/share/keyrings/debian-keyring.gpg
protobuf-c_1.5.1-1.dsc 1>/dev/null
gpgv: Signature made Sun Feb 2 00:10:24 2025 -05:00
gpgv: using RSA key DF3D96EEB3827820F302665C01817AB0AAF6CDAE
gpgv: Good signature from "Robert Edmonds <edmo...@mycre.ws>"
gpgv: "Robert Edmonds <edmo...@debian.org>"
$ dscverify --verbose --no-default-keyrings --keyring
/usr/share/keyrings/debian-keyring.gpg protobuf-c_1.5.1-1.dsc
protobuf-c_1.5.1-1.dsc:
gpg: Signature made Sun 02 Feb 2025 12:10:24 AM EST
gpg: using RSA key DF3D96EEB3827820F302665C01817AB0AAF6CDAE
gpg: Good signature from "Robert Edmonds <edmo...@mycre.ws>" [unknown]
gpg: aka "Robert Edmonds <edmo...@debian.org>" [unknown]
gpg: WARNING: Using untrusted key!
Good signature found
validating protobuf-c_1.5.1.orig.tar.gz
validating protobuf-c_1.5.1-1.debian.tar.xz
All files validated successfully.
That makes sense, since only my encryption subkey is affected.
The "gpg --edit-key" instructions on the lore.kernel.org page you
linked did not work for me. (I use an OpenPGP hardware card and have not
investigated Sequoia's support for hardware keys.)
I did find this blog post:
https://blog.bmarwell.de/2020/11/21/fixing-old-sha1-infested-openpgp-keys.html
And the command "gpg --quick-set-expire <key-fingerprint> 0 '*'" listed
on that page worked to replace the self-signature on the encryption
subkey. Now I have the following signature packet with "digest algo 10"
(SHA-512) rather than "digest algo 2" (SHA-1):
# off=2850 ctb=89 tag=2 hlen=3 plen=566
:signature packet: algo 1, keyid 01817AB0AAF6CDAE
version 4, created 1742767476, md5len 0, sigclass 0x18
digest algo 10, begin of digest 93 60
hashed subpkt 27 len 1 (key flags: 0C)
hashed subpkt 33 len 21 (issuer fpr v4
DF3D96EEB3827820F302665C01817AB0AAF6CDAE)
hashed subpkt 2 len 4 (sig created 2025-03-23)
subpkt 16 len 8 (issuer key ID 01817AB0AAF6CDAE)
data: [4095 bits]
With this new signature, the "sq cert lint" command does not print any
red text to the terminal now.
But, again, this is a self-signature on an encryption subkey and I do
not see how that should affect the verification of signatures made from
the signing key on .dsc, .changes, etc. files.
--
Robert Edmonds
edmo...@debian.org
