On Wed, Oct 21, 2026 at 11:26:30AM +0200, Julian Andres Klode wrote: > Contrl: severity -1 minor > > On Wed, Oct 21, 2026 at 02:31:26AM -0400, Christian Noé Ramos López wrote: > > Package: apt > > Version: 3.0.3 > > Severity: normal > > X-Debbugs-Cc: [email protected] > > > > > > > > > > With sqv, the default method in apt 3.0.3, three forms of Signed-By > > that sources.list(5) documents no longer work. A repository that uses > > any of them fails as not signed, where the gpgv method accepts it. > > > > sources.list(5) has Signed-By take "fingerprints of keys to select > > from these keyrings", and an appended "!" stops a fingerprint from > > also accepting "signatures by a subkey of this key". With K a primary > > that only certifies and has a signing subkey, P a primary that signs, > > and both in the keyring named before the fingerprint: > > > > Signed-By fingerprint signed by gpgv method sqv method > > K's subkey K's subkey accepted refused > > K's subkey, with "!" K's subkey accepted refused > > P, with "!" P accepted refused > > > > Each row is apt-get update on 21 October 2026, apt 3.0.3 with sqv > > 1.3.0 or gpgv 2.4.7, a file:// repository and a fresh root: accepted > > means the InRelease landed in lists/, refused means "No good signature > > from required signer: <fingerprint>" and "is not signed". Two runs > > with new keys agree, and so do the controls under both methods: K's > > primary is accepted for its subkey's signature, and P is refused > > for it. > > > > apt's own test already skips the subkey case for sqv: "This is only > > supported for gpgv, so require an explicit gpgv command, otherwise the > > default verification backend may be sqv." > > (test/integration/test-releasefile-verification). The answer to > > #863317 in 2017 was to pin keys with Signed-By: "you have to pin both > > the master and the subkeys (actually only the latter)". With sqv it is > > the other way round: the subkey alone is refused, and only the master > > matches. > > Yes this is not implemented or implementable - sqv returns us the > primary key it verified with. > > Given that key pinning is a bit antithetical to the whole idea of > key files being atomic units, and also has been universally phased > out in other ecosystems, it seems reasonable to remove it going > forward. > > Manual pages we could remove the mention of subkeys immediately, > or all mentions of key pinning.
Deprecating fingerprints in https://salsa.debian.org/apt-team/apt/-/merge_requests/633 as well as removing Signed-By pinning inside the Release file which nobody used. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
