On Mon, 2014-09-15 at 00:04 +0200, Stefan Lippers-Hollmann wrote: > Please consider that too short intervals (24h might still work, but > it's hard on the limit) make non-primary (cron based) mirrors basically > impossible. Including local mirrors used for systems that can't connect > to the internet directly or potentially even setups used for (personal) > archive-wide rebuilds or debian-cd related tasks. Intervals below an > hour, besides probably even invalidating most primary mirrors, are > likely to render apt-get update to expire before it has finished > downloading the meta data for all repos on slower internet connections. Well as I've said in my post before: such slow systems should just need to resync the (re-signed) metadata files at a more current point.
But of course you're right, extremely slow mirrors and/or pull models are likely to cause troubles (or break), but their working model is simply broken, at least with respect to security. > Decreasing these validity cycles too much would force many of these > uses to ignore expiry times alltogether - or having to re-sign a local > archive mirror with longer periods (which is not exactly a reasonable > task for most users or anything that involves debootstrapping). I guess > most uses would opt to go with the first option instead, which won't > help anyone... Well, users can always take a gun and shoot themselves. No reason to expose *all* users to security issues, if there is (small?) fraction of users who would just completely deactivate secure APT, if it means too much effort for them. I mean that's basically always the problem with security, isn't it? You don't get it for free, which is why we have crap like the Internet's X.509 certificate hierarchy that basically fails and breaks and all points. If a really strong (i.e. meshed) system would have been used, many end-users would have refused to use it altogether, wich is why we have a system now, that is basically useless for all. > Personally I think 24 hours (better something like 26-28 hours to allow > some overlap for secondary/ tertiary/ local mirrors only updated daily) > would be the technical limit that might be possible, but anything > shorter than a week (or at very least three days) would already > significantly impact many valid use cases where local mirroring and/or > a fixed archive state is required. Don't you think it would be possible for mirrors, to have faster resync of just the meta-datafiles? I mean these are really small, and actually it should be only necessary to frequently resync the [In]Release* files, if everything else stayed the same, only they will have changed for the new validity times. > While there might be an argument to decrease the expiry times for > security.d.o, perhaps even down to a day or at least half a day[1], the > negative net impact for all normal archives (especially testing and > unstable) would imho far outweigh any potential security improvements. Why? I guess many people use e.g. sid as their main system, so all of them will get their security upgrades via that and not via security.d.o. So they would be still left vulnerable downgrade attacks in case of such things like the bash/apt holes from these days, even though Debian might have perfectly reacted and already supplies fixed packages. > Just look at the common advice given for expired signatures on > snapshots.d.o, most suggest to use a global > > apt-get -o Acquire::Check-Valid-Until=false update > or > Acquire::Check-Valid-Until "0"; > > for apt. Well sure, but snapshots.d.o is a completely different story, isn't it? Everyone using it, should be aware that these are old archived packages, and that it's not so unlikely that they contain security issues. In other words, there is no implicit guarantee in any way that snapshot.d.o gives you secure stuff - therefore we don't need to defend against things like blocking/downgrade attacks. > For these reasons I would suggest against changing the current > intervals, especially least not into the hour- or single day regions. Well I think the current intervals (what were they? 1 month?) are *far* too long. If there should be really insolvable technical issues (and I guess most of them might be solved by quickly resyncing the [In]Release* files, which should be trivial)... than one day is probably the interval I'd go for. Cheers, Chris. >
smime.p7s
Description: S/MIME cryptographic signature
