Re: Expired GPG keys of older release
- Date: Fri, 22 Jun 2018 23:48:00 -0500
- From: David Wright <deblis@xxxxxxxxxxxxxxxxx>
- Subject: Re: Expired GPG keys of older release
On Fri 22 Jun 2018 at 21:12:51 (+0200), tomas@xxxxxxxxxx wrote:
> On Fri, Jun 22, 2018 at 02:39:52PM -0400, James Cloos wrote:
> > >>>>> "T" == <tomas@xxxxxxxxxx> 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
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.