Forums before death by AOL, social media and spammers... "We can't have nice things"
|    linux.debian.bugs.dist    |    Ohh some weird Debian bug report thing    |    28,835 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 27,977 of 28,835    |
|    Julian Andres Klode to kpcyrd    |
|    Bug#1127595: [Pkg-rust-maintainers] Bug#    |
|    17 Feb 26 12:00:01    |
      From: jak@debian.org              On Tue, Feb 10, 2026 at 02:59:17PM +0100, kpcyrd wrote:       > 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)".              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.              --       debian developer - deb.li/jak | jak-linux.org - free software dev       ubuntu core developer i speak de, en              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca