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)".
The update-withholding defense in apt can be turned off with `-o
Acquire::Check-Valid-Until=false`, I'd rather prefer if there were no further
time based logic bombs.
cheers,
kpcyrd
