On Mon, Dec 09, 2024 at 03:41:39AM +0100, Guillem Jover wrote: > This is a consequence of the switch from gpg to gpgv, which has now > surfaced issues in how the certificates are stored in the Linux > packaging (and while checking this also in the certificates themselves). > The first issue is that the debian/upstream/signing-key.asc uses > concatenated ASCII Armored certificate blocks, which is not a well > defined construct, see: > > <https://bugs.debian.org/969588> > <https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/28> > <https://bugs.debian.org/969590>
According to codesearch, about 1/6th - 1/5th of the packages providing debian/upstream/signing-key.asc have multiple certificate blocks. https://codesearch.debian.net/search?q=-----BEGIN+PGP+PUBLIC+KEY+BLOCK-----+path%3Adebian%2Fupstream%2Fsigning-key.asc&literal=0 vs https://codesearch.debian.net/search?q=-----END+PGP+PUBLIC+KEY+BLOCK-----%5Cn-----BEGIN+PGP+PUBLIC+KEY+BLOCK-----+path%3Adebian%2Fupstream%2Fsigning-key.asc&literal=0&perpkg=1 > The other is that many certificates listed there should not be considered > valid anyway as they use weak constructs (gpgv from GnuPG currently > considers them fine but gpg-from-sq for example will not, and neither > any of the other SOP implementations), and that also reminds me that we > should be passing to gpg/gpgv in uscan and any other devscripts > invocation «--weak-digest SHA1 --weak-digest RIPEMD160» (I'll queue a > patch in my upcoming GnuPG cleanup branch). > > Running either «sq inspect debian/upstream/signing-key.asc» or > «sq cert lint --cert-file=debian/upstream/signing-key.asc» (from sid) > will show issues such as: > > <snip> > > So you might also want to contact upstream developers to sort out their > certificates. While these may very well be issues that upstream should consider, is it really uscan's role to be enforcing these strict policies? These are the keys that upstream has signed with, so why should we be considering that an error? I could see emitting a warning, so there's some data to send back to upstream when explaining why they may want to revisit their keys. However, by the time we're downloading and verifying the artifacts, it's kinda too late, isn't it? This also isn't a good story for downloading older versions, since what's considered "secure" may have changed in the intervening time. It can still be useful to validate what existed, even if it's not up to contemporary standards. Cheers, -- James GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
