On Sun, Dec 08, 2024 at 10:49:05PM -0500, James McCoy wrote: > 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.
ouch. thanks for that data point.
> > 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 tend to agree...
> 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.
Yes, definitly for some grace period.
> 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.
agreed as well.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄
🎵 Covid seems to be the hardest word. 🎵
signature.asc
Description: PGP signature
