Am Tue, Feb 10, 2026 at 09:08:30PM +0100, schrieb Alexander Kjäll: > > 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. > > If this is a desired property, shouldn't there rather be an expiration date > set on the signature?
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
signature.asc
Description: PGP signature
