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.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en

Reply via email to