[Pkg-rust-maintainers] Bug#1127595: Apt allows expired keys for repos

[David Kalnischkies]

Am Tue, Feb 10, 2026 at 10:17:39AM +0100, schrieb Julian Andres Klode:
> Control: reassign -1 rust-sequoia-sqv
> Control: tag -1 security

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)


> On Tue, Feb 10, 2026 at 09:02:47AM +0100, Johannes Kress wrote:
> > 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 at example.com>
> > Got EXPKEYSIG 9B60EA63B19DD085 Repo Signing Key<repos at 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 at 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 at 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 at 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.
> 
> 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)


Best regards

David Kalnischkies

(Our testcases use an expired key to sign expired test repos, which
 hides this particular difference, I suppose)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-rust-maintainers/attachments/20260210/d5b5bcd1/attachment-0002.sig>