Comment 2 for bug 247445

So, I agree with this bug, although I think that it is primarily relevant to security.ubuntu.com. The main release pocket doesn't change after release anyway, and I think most people running development releases will get itchy if there are no updates for several days (they certainly seem to during freezes!). Attaching this condition makes it easier to fix this bug, because we direct all Ubuntu users to security.ubuntu.com rather than to mirrors, so this means we don't have to worry about how to balance rapid notification of risk against slow mirror update frequencies. (We don't want to issue incorrect security warnings any more than we want to fail to notify users of attacks.)

I had a discussion with James Troup (who runs our system administration team) and we agreed that we should do the following:

"
 a) regenerate the -security Release files at least twice a day
 b) modify apt to freak out if a -security Release file is > 1 day old (this should probably be a configuration option so that the trip point is configurable but also we only want to trigger on security.ubuntu.com, not a mirror.)

This closes off the 'MITM with a stale archive' avenue of attacks.

The downsides (that I can immediately think of) are:

 a) increased traffic on security.ubuntu.com (fine by me - since the "alternative" is https ;-)

 b) we _have_ to keep updating security.ubuntu.com. We can't have the publisher cron jobs down for more than a day (? possibly less) or so without making millions of users freak out.
"

I therefore suggest that apt should grow a configuration option to set a per-host maximum age for mirror files, which is checked on update. There's already APT::Acquire::mirror::MaxAge, which suggests the obvious extension APT::Acquire::mirror::security.ubuntu.com::MaxAge. Could we arrange for a desktop notification when this age is exceeded, if there isn't one already?

Of course, this needs to be checked only on update (the user simply not bothering to run 'apt-get update' doesn't correspond to a stale-archive attack). We should also consider what to do about transient network failures: on the one hand, we don't want to claim that an attack is in progress when the user simply didn't bother to connect to the network for a couple of weeks; on the other hand, the simplest stale-data attack for an evil ISP is simply to null-route security.ubuntu.com. What do people think?