On Fri 22 Jun 2018 at 21:12:51 (+0200), to...@tuxteam.de wrote: > On Fri, Jun 22, 2018 at 02:39:52PM -0400, James Cloos wrote: > > >>>>> "T" == <to...@tuxteam.de> writes: > > > > T> And just extending the keys' validity (as someone proposed in this > > T> thread) seems a bad idea too, since the requirement for secure keys > > T> evolves over time, as the NSA^H^H^H bad guys buy more GPUs. > > > > The problem is that the point of a key's expiration time is that > > signatures newer than that should fail, but all signatures made before > > the expiration should verify. > > Makes sense... > > > So, if apt's signature verification only looks at the key's expiration > > date and not at the signature's timestamp, that is a bug. > > Hm. But a stern warning (along the lines "this signature isn't as secure > as it used to be") seems in order, no? > > For the current case, what's needed most is some kind of workaround, since > an old apt can't be fixed retroactively, though.
Well, I attempted to supply that in https://lists.debian.org/debian-user/2018/06/msg00528.html but I have no idea whether that would be achievable in docker or not because the suggestion has had no follow-up. BTW Reading your "Keys *have* to expire at some point, and you can't re-sign archived packages with a fresh key", it's not clear why the expired key can't be unexpired, ie given an expiration date in the future, if it's known to be still good. Cheers, David.
