On Tue, Feb 10, 2026 at 02:59:17PM +0100, kpcyrd wrote: > On 2/10/26 12:21 PM, David Kalnischkies wrote: > > > This is Sequoia's expected behavior provided the signature was created > > > before > > > the key expiration. I don't think it's the most sensible notion but it's > > > outside of our control, as long as we don't want to patch that in Debian > > > to behave differently. > > > > As can be seen by the debug output of our gpgv method gpgv actually has > > similar behaviour (exit code 0) – it is the special handling in our gpgv > > method that detects that gpgv produced a VALIDSIG, but not a GOODSIG (and > > instead a EXPKEYSIG). > > > > > > IF that is a desired property to be similar in this regard to gpgv is > > something to be decided by upstream, but a feature request to enable > > a mode that considers them bad enough to fail might be in order. > > > > The idea here is that a repo with an expired key (think e.g. buster) > > should not be used even if that repo was correctly signed back in the > > day as the data the key signed is sort of expired by now, too. > > > > (similar to our Valid-Until field… but that is not universally used) > > > Does this really matter in praxis though? > > The expiration date on PGP keys is often confused with the expiration on > x509 certificates, which is a proper security control enforced through a 3rd > party. > > With OpenPGP keys the expiration date is quite literally a self-signed > certificate, if the secret key is compromised you can arbitrarily issue new > Type 9 Key Expiration Time Subpackets, including "0 (Unlimited)".
Yes but you cannot update the keys on existing APT clients; APT's key store does not have facilities to update it over the network. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
