Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
- To: Santiago Vila <email@example.com>
- Cc: firstname.lastname@example.org, email@example.com
- Subject: Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files
- From: Ian Jackson <firstname.lastname@example.org>
- Date: Mon, 3 Nov 2014 17:56:15 +0000
- Message-id: <[🔎] email@example.com>
- In-reply-to: <20141031153118.GA29422@nuc>
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20140929110845.GA20150@khazad-dum.debian.net> <email@example.com> <firstname.lastname@example.org> <email@example.com> <20141031114804.GB1931@client.brlink.eu> <20141031153118.GA29422@nuc>
Santiago Vila writes ("Re: Bug#752450: ftp.debian.org: please consider to strongly tighten the validity period of Release files"):
> I have a laptop with testing which I use mostly on weekends. I have a
> partial mirror there, which I try to update as soon as I login into
> the system.
Firstly, I think this is an important use case which we should cater
to. But also I think we should try to reduce the risk of the kinds of
attacks that Christoph Mitterer is worried about.
I think that we should approach this problem in the best Debian
tradition and try to invent some kind of technical approach that
works, as well as we can arrange, for everyone.
Certainly just changing the validity period for the signatures is too
blunt a tool. As demonstrated, there is no right value for this
configuration parameter. IMO that shows that we have a design
problem. We should fix that, rather than having an argument about
which use case is more important.
Indeed, the time interval between vulnerabilities being known and
being widely exploited is becoming very short. We need to speed up
our distribution of security patches, if we can, and that means we
need to reduce the rollback vulnerability window.
I don't have a complete recipe for this but here are some possible
* The computer knows when it last polled for updates from whatever
its mirror is. Perhaps this information is of use.
* We could run a lightweight polling service on Debian infrastructure
which the computer could use to find out how out of date it is.
* We could provide a separate command or tool or option to check for
security updates - a tool which would _fail_ if the network and
infrastructure was not sufficiently working.
* We could provide a configurable addition to the validity period.
* The security archive might want a different validity period.
* We might want automation which was capable of automatically
shutting a server down into some kind of minimal maintenance mode,
when it is unable to verify its own security support status.
* Some people here have already suggested that `desktop' and `server'
configurations might want different defaults. `Laptop' probably
wants yet different defaults.
> This is a real pain and it reminds me of "subscription" services or
> DRM stuff, like those games that fail to work if the player is not "online".
As someone who is running various servers, I would love it if my
server shut itself down if it thought it was `offline' because it
couldn't do its security updates. Of course, conversely, that would
be incredibly annoying for my netbook!