When a key for an apt repo expires the key will be still accepted by apt
I tested it by setting up an apt repo and created an expired key
Then i run apt update with the debugging option for sqv on apt 3.0.3:

$ apt -oDebug::Acquire::sqv=true update
Hit:1https://repos.example.com/deb stable InRelease
0% [Working]Setting SEQUOIA_CRYPTO_POLICY=/usr/share/apt/default-sequoia.config
Executing /usr/bin/sqv --keyring /etc/apt/keyrings/expired.gpg /tmp/apt.sig.rBMAZ6 /tmp/apt.data.d4Yp1h --policy-as-of 2027-2-10
sqv exited with status 0
Got GOODSIG 5D276A38B044FF63B56B08669B60EA63B19DD085
sqv succeeded
All packages are up to date.

When using the same repo with apt 2.6.1 you got the following error:

$ apt -oDebug::Acquire::gpgv=true update
Get:1https://repos.example.com/deb stable InRelease [1204 B]
0% [Working]inside VerifyGetSigners
Preparing to exec:  /usr/bin/apt-key --quiet --readonly --keyring /etc/apt/keyrings/expired.gpg verify --status-fd 3 /tmp/apt.sig.VDLBNK /tmp/apt.data.hS31kv
Read: [GNUPG:] NEWSIG
Read: [GNUPG:] KEY_CONSIDERED 5D276A38B044FF63B56B08669B60EA63B19DD085 0
Read: [GNUPG:] KEYEXPIRED 1770546861
Read: [GNUPG:] SIG_ID MCZNnca4nxaNt/A1F1XT6RADCbo 2026-02-03 1770114959
Read: [GNUPG:] KEY_CONSIDERED 5D276A38B044FF63B56B08669B60EA63B19DD085 0
Read: [GNUPG:] EXPKEYSIG 9B60EA63B19DD085 Repo Signing Key<repos@example.com>
Got EXPKEYSIG 9B60EA63B19DD085 Repo Signing Key<repos@example.com> !
Read: [GNUPG:] VALIDSIG 5D276A38B044FF63B56B08669B60EA63B19DD085 2026-02-03 1770114959 0 4 0 22 8 01 5D276A38B044FF63B56B08669B60EA63B19DD085
Got trusted VALIDSIG, key ID: 5D276A38B044FF63B56B08669B60EA63B19DD085
gpgv exited with status 0
Summary:
   Good:
   Valid: 5D276A38B044FF63B56B08669B60EA63B19DD085
   Bad:
   Worthless: EXPKEYSIG 9B60EA63B19DD085 Repo Signing Key<repos@example.com>
   SoonWorthless:
   NoPubKey:
   Signed-By:
   NODATA: no
Err:1https://repos.example.com/deb stable InRelease
   The following signatures were invalid: EXPKEYSIG 9B60EA63B19DD085 Repo Signing Key<repos@example.com>
Reading package lists... Done
W: GPG error:https://repos.example.com/deb stable InRelease: The following signatures were invalid: EXPKEYSIG 9B60EA63B19DD085 Repo Signing Key<repos@example.com>
E: The repository 'https://repos.example.com/deb stable InRelease' is not signed.
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.

I tested this on Debian 13 and debian 12 with the latest updates installed.

Control: reassign -1 rust-sequoia-sqv
Control: tag -1 security

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.

Am Tue, Feb 10, 2026 at 10:17:39AM +0100, schrieb Julian Andres Klode:

CC'ing the package maintainers as recommended by the dev-ref (§5.8.3.2)
for a reassign, just to be sure they actually see it (which, I suppose,
this reply achieves by itself already, but as a reminder for next time)

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)


Best regards

David Kalnischkies

(Our testcases use an expired key to sign expired test repos, which
 hides this particular difference, I suppose)

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

Hi
set on the signature?

See: https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/packet/signature/struct.Signature6.html#method.signature_validity_period

//Alex

Am Tue, Feb 10, 2026 at 09:08:30PM +0100, schrieb Alexander Kjäll:

Maybe that is the correct technical solution, but good luck telling that
each and every repository owner, which then have to adapt all their
generation tools ~ and invent a time machine to use these tools years
ago.

(You could argue that setting every signature to expire is error prune
 and a bit silly if you can treat key expiry as default value, but okay)


If you want, you can also view key expiry as a dead man's switch key
revocation that actually works in our context as key updates (which
would make an actual key revocation possible) are not usually done:

Assuming an attacker manages to get hold of busters secret key now, they
can unexpire the key – but they can not really ship this update to users.
What they can do is use `faketime` to sign a Release file just before
the original key expired that will be accepted by sqv as valid;
while gpgv (+ our methods logic) will refuse it.

(The move to Signed-By drastically reduced the surface of this problem)


Best regards

David Kalnischkies

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.