On Fri, 2024-11-29 at 09:27:57 +0100, Julian Andres Klode wrote: > On Fri, Nov 29, 2024 at 03:31:58AM +0100, Guillem Jover wrote: > > Package: apt > > Version: 2.9.15 > > Severity: serious > > Justification: I pondered initially on important, but given that this > > is a regression that prevents repo usage, it seems worth serious to me.
> > The latest release made some repos stop working as apt is now refusing > > to use the specified keyring when it ends in «.pgp» > > You essentially exploited a bug in apt-key where it was not correctly > checking single signing keys and worked around the documented behavior. I don't think I've ever used apt-key for this specific keyring though, this had always been provided as part of an archive-keyring kind of package, installed under /usr/share/keyrings, and used through a Signed-by field in a «.sources» list file. In any case, thanks for the fix! > This poses a tricky question for us because it means there's not just > .pgp possibly, maybe someone named their keys .banana. Yes, that also crossed my mind. > But I think we can fix this: We move the else if for .asc up, > drop the extension check on the binary file verification and add > a warning to use `.pgp` if you specify a weird one like `.banana` Right, emitting warnings for unexpected extensions for a while might be better than outright refusing to process the keyrings. Then after a while (say one release cycle) those can start erroring out maybe? I guess ideally even .gpg could get a warning or info or hint-like message directing people to rename? But that could be way more disruptive or unactionable from the admin side, as long as the keyring packages only provide .gpg files, although I'd still like to go over the various keyring packages and provide patches for a transition from .gpg to .pgp with compat symlinks, which I'd like to do before the release. (Maybe as an alternative a warning/info/hint could be emitted if the keyring extension is .gpg *and* it's a symlink to a .pgp keyring file with the same basename or some heuristic like that, to help the migration.) But I guess your plan of just accepting .asc, .pgp, and .gpg, and warning to rename to .pgp for other extensions would be the safest less disruptive path for now. > > Enforcing «.gpg» (and «.asc») as the only allowed extensions seems > > wrong, because «.gpg» is an implementation specific name, which does > > not match the standard (OpenPGP) this is based on, where the more > > neutral name to use is «.pgp». So either «.pgp» should be explicitly > > allowed or the extension and format checks should be removed, as the > > OpenPGP implementation in use should be able to reject unknown > > keyrings. > > Tell that to GnuPG :D > > $ gpgv --keyring $PWD/COPYING --keyring > /usr/share/keyrings/ubuntu-archive-keyring.gpg > /var/lib//apt/lists/_etc_apt_mirrors.list_dists_plucky_InRelease > gpgv: Signature made Fr 29 Nov 2024 08:41:32 CET > gpgv: using RSA key F6ECB3762474EDA9D21B7022871920D1991BC93C > gpgv: [don't know]: invalid packet (ctb=46) > gpgv: keydb_search failed: Invalid packet > gpgv: [don't know]: invalid packet (ctb=46) > gpgv: keydb_search failed: Invalid packet > gpgv: Can't check signature: No public key Ah, right I remember now that kind of output from gpg*. > $ gpgv-sq --keyring $PWD/COPYING --keyring > /usr/share/keyrings/ubuntu-archive-keyring.gpg > /var/lib//apt/lists/_etc_apt_mirrors.list_dists_plucky_InRelease > gpgv: error: Loading keyring "/home/jak/Projects/Debian/apt/COPYING" > gpgv: because: EOF > gpgv: error: Reading the keyring "/home/jak/Projects/Debian/apt/COPYING" > gpgv: because: Loading keyring "/home/jak/Projects/Debian/apt/COPYING" > gpgv: because: EOF > gpgv: Signature made Fri Nov 29 08:41:32 2024 +01:00 > gpgv: using RSA key F6ECB3762474EDA9D21B7022871920D1991BC93C > gpgv: Good signature from "Ubuntu Archive Automatic Signing Key (2018) > <ftpmas...@ubuntu.com>" (And I guess gpg*-sq being bug compatible here.) Thanks, Guillem
