On Thu, Sep 25, 2008 at 04:11:29PM +0200, Joerg Jaspert wrote: > (It would be easy to regenerate it weekly, while having it expire after > 30 or 60 days. Now, stable itself doesn't change so often, only for > point releases. And its also not security related, as those get in via > the security archive, which does have a proper setup for valid-until > (and will get em when the code is fully synced, so this weekend i > think.)
But releases do not expire. Thus a valid-until does not make sense semantically, too, IMHO. Of course security must have it. > > But if we could specify that it does not expire (which is IMHO true) > > that would solve that issue. > No (archive side). While we could go and add the special string "Never", > this won't help us, as we are then back to the known problem, that a > MitM can go and do bad things to you (this time by *also* modifying the > release file, but hey, thats no bigger task then getting in between you > and $world first). Of course he could modify the release file, but it's GPG-signed, or I don't get your point. And no, all important security-relevant updates are still present through security.d.o, which is protected. All the user would not get due to an outdated or bad mirror are the updates from proposed-updates included into the latest point release. Kind regards, Philipp Kern -- .''`. Philipp Kern Debian Developer : :' : http://philkern.de Release Assistant `. `' xmpp:[EMAIL PROTECTED] Stable Release Manager `- finger pkern/[EMAIL PROTECTED]
signature.asc
Description: Digital signature
