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<[email protected]> > > Got EXPKEYSIG 9B60EA63B19DD085 Repo Signing Key<[email protected]> ! > > 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<[email protected]> > > SoonWorthless: > > NoPubKey: > > Signed-By: > > NODATA: no > > Err:1https://repos.example.com/deb stable InRelease > > The following signatures were invalid: EXPKEYSIG 9B60EA63B19DD085 Repo > > Signing Key<[email protected]> > > Reading package lists... Done > > W: GPG error:https://repos.example.com/deb stable InRelease: The following > > signatures were invalid: EXPKEYSIG 9B60EA63B19DD085 Repo Signing > > Key<[email protected]> > > 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)
signature.asc
Description: PGP signature
