From: david@kalnischkies.de   
      
   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/def   
   ult-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   
   > > Got EXPKEYSIG 9B60EA63B19DD085 Repo Signing Key !   
   > > 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   
   > >   SoonWorthless:   
   > >   NoPubKey:   
   > >   Signed-By:   
   > >   NODATA: no   
   > > Err:1https://repos.example.com/deb stable InRelease   
   > >   The following signatures were invalid: EXPKEYSIG 9B60EA63B19DD085 Repo   
   Signing Key   
   > > Reading package lists... Done   
   > > W: GPG error:https://repos.example.com/deb stable InRelease: The following   
   signatures were invalid: EXPKEYSIG 9B60EA63B19DD085 Repo Signing   
   Key   
   > > 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)   
      
   -----BEGIN PGP SIGNATURE-----   
      
   iQIzBAABCgAdFiEE5sn+Q4uCja/tn0GrMRvlz3HQeIMFAmmLFKgACgkQMRvlz3HQ   
   eINtjA//UoQSt0H4etgTjjp1x4BsZgMFLk9sncd4swhcJqsreKqnjFnJflh29yMA   
   r/G/L9zW5gQhvkelxeW6tziyVI1xvLNrhPbyVBbio7qJIEI9rvOJrackWulzuJtI   
   17kV6FQ85qQFqFqiUb8cyQ2xkkasgCR+AWJ4z0ZmYtPrL5gqariuh4DLX7dDo4RV   
   EB32v/Ru//QItr/0SY6o7CqOxkKltei084juX+aVED8w6gx6UgT7Z6S2KA4oF6tF   
   FOi7OcBmoUSKKN55uUOQi9RNRy1uSJzCSKBdAO+YPVZVG5F5WY/rbcAb2zgdUHyS   
   MdbqyXzItw42ed59AklGDUjtl0+iPuoQVykkadOyXs9veQTwKOk6kyah3GKl/n0/   
   MT0QD+54bNZe4Cm7IWYVpktcTOz5DE+v+FeMiY8GMk4PgmTvbUws1+hb13mCXVcd   
   FqZ0eS8UpphecD6gdGosOR3Hn9RrRK9JSNV6hlcmeZAnKDtdgRo+htXqwl9KWid6   
   rhHcz1yTje41BPfBjs4xuJiwpXqC8LNvbHFgPpSyv6gTbJRyAGiASZRH4bR/WxGs   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)