Hey Joerg. On Sun, 2014-09-14 at 21:52 +0200, Joerg Jaspert wrote: > Technically we could go down to 1 second, validtime is expressed in > seconds in our setup. ;-) > > My proposal would be something like that: > > unstable/testing: 4-12 hours > > [wheezy|squeeze]/updates at security.d.o: 1-6 hours > > I'm not sure going below a dinstall cycle is useful. Probably even two. > Have it expire before the new stuff even got a chance to get out is not > a good idea, IMO. Are there any numbers how long it actually takes for the stuff to get distributed? But apart from that, even if it take a while for the actual package files to distribute through all the mirrors, once that is done, only the re-signed meta-data files would need to be distributed, which should be quite fast. So if copying is done smart, I'd guess this could be made to work. Anyway, even if there are technical issues, don't you think that it sounds kinda stupid, if all the distros and security guys try to orchestrate the publication of important issues (like the apt or bash stuff we've seen these days), so that basically fixed packages could be available for all distros at nearly the same time, while we still leave our users basically vulnerable by having far too long validity times. > Also, going down to such small intervals means we MUST resign, even if > there is no update at all in the archive (so an extra cronjob, just to > be sure). Sure, I mean that's the whole point of constantly and frequently assuring that the package meta-data (including it's information about security things) is current... doing these resigns often is basically what prevents downgrade/blocking attacks. > That's no problem in the main archive, there is always enough > going on, but security can go way longer without an update (which is why > such a (weekly) cronjob exists on security). So does this mean that it *would* be a problem for e.g. non-main archives? > That is technically not a big problem. Unless you happen to look at > services like snapshot, which run an import on every trigger. No idea > how much it hurts them if only the Release files change, need to find out. Well I think snapshot is it's own construction site, isn't it? IIRC, snapshot ships the old Release files, and thus everything older than a few weeks is anyway considered invalid, right? And doesn't it also use the old GPG keys? IMHO that makes it a bit difficult to use snapshot.d.o. I think it would be better if there was a special GPG key for snapshot.d.o. As for the Release files and their validity, one could go probably two ways: - constantly resign them (or give them basically infinite validity), thereby making it easy to use it (i.e. no warnings from APT), assuming that it is clear to everyone who uses snapshot.d.o that these packages are not current and probably full of security issues. - leaving it as is, i.e. keep the original expiration times in the Release files and people must manually tell their APT/aptitude/etc. to ignore this. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature