Hi On Sunday 14 September 2014, Joerg Jaspert wrote: > 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: [...] > > 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.
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.
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...
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.
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.
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.
For these reasons I would suggest against changing the current
intervals, especially least not into the hour- or single day regions.
Regards
Stefan Lippers-Hollmann
[1] and even for security.d.o I don't believe that anything below at
least 2-3 days would be a good idea.
signature.asc
Description: This is a digitally signed message part.
