On 13616 March 1977, Christoph Anton Mitterer wrote: [ Not doing a full quote, but keeping quite a bit of context for debian-devel readers ] > As Jakub Wilk pointed out[1] these are the current validity periods > for Release files: > unstable, experimental: 7 days > testing: 7 days > wheezy: no limit > wheezy(-proposed)-updates: 7 days > wheezy/updates at security.d.o: 10 days > wheezy-backports: 7 days > squeeze: no limit > squeeze(-proposed)-updates: 7 days > squeeze/updates at security.d.o: 10 days > squeeze-lts: 7 days > IMHO all of them are far too long. > Maintainers and our Security Team are usually doing a great job in > trying to provide fixes for security issues ASAP. > But even if they're incorporated only hours or less after being > released, an attacker can do a downgrade attack for 7-10 days and > trick a system into not "seeing" these new packages. > Such downgrade attack is very easy to perform, as soon as one can > MitM, and we generally must expect that not only powerful groups > like NSA and friends are able to do this. > Since many unattended systems (especially in the stable branches) > are more or less automatically updated, and since an attacker that > can MitM can likely also block any security announcement mails, > users/admins have no chance to take note about such updates being > available for 7-10 days. > I'd suggest to reduce the validity to at most 1 day in all cases. > Actually I'd choose much smaller values if this causes no other > problems. Technically we could go down to 1 second, validtime is expressed in seconds in our setup. > Many users run unstable/testing as their normal system, so it's > not enough to only tighten the periods for the stable branches. > 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. 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). 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). 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. Same goes for any service that starts $whatever-heavy-action on a mirror trigger. If they don't check that nothing else changed, they may waste loads of cpu. (Of course we also force users to update way more often) So, now, CC-ed debian-devel to get more input on what a good time for the Release files validity would be. I'm happy to change it to whatever is deemed best, but instead of just changing and waiting for fallout, I would like some more input up front. -- bye, Joerg Yeah, patching debian/rules sounds like changing shoes while running the 100 meters track. -- Michael Koch
Attachment:
signature.asc
Description: PGP signature