Hi Ian. In principle I've had left this discussion for previously stated reasons, but since you're one of the few who actually seems to be willing to discuss about this on a technical level with real arguments and ideas some replies to them:
On Mon, 2014-11-03 at 17:56 +0000, Ian Jackson wrote: > IMO that shows that we have a design > problem. The thing is IMHO just, that that the issues have these problems inherently. - when one wants short validity times (for the reasons pointed out several times now), then may run into availability problems *unless* one deals with them on a technical level, as I've proposed some times now - when one makes the whole thing optional for security paranoid users, then it's likely that it won't work very well vor them (due to only few people taking care about it)... and the majority looses any possible benefit. Now to your ideas: > * The computer knows when it last polled for updates from whatever > its mirror is. Perhaps this information is of use. In principle yes,... though this may be a complex/error-prone information,... thinking about multiple different repos with different last-checked times (some of them may have been down, or simply not checked)... > * We could run a lightweight polling service on Debian infrastructure > which the computer could use to find out how out of date it is. I personally would probably strongly vote against such model. It's basically the same as with OSCP, and we've seen how well that works. Decoupling certain security assertions from that actual object being secured leads to all kinds of problems,... And it opens again the question: what to do when this polling service is down (or DoS attacked)? Which is basically the same question as to my basic proposal of just changing the validity times. Either one would ignore the polling service being down (which makes the whole thing useless as OSCP is for most browsers) or one would make it a failure communicated to client - which is not different to what I've proposed what should happen when the clients encounter a expired Release file. > * 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. Intuitively I'd say, that this makes usability of everything just more difficult. One would always need to use that tool in addition, need to adapt 3rd party programs for it. And either, you wouldn't enable that tool per default (which makes it again useless for the majority)... or you would, which would bring back all the points from my critics. > * We could provide a configurable addition to the validity period. I think we already have that, don't we? But it doesn't solve the problem, at least unless the Release files would be much more frequently resigned. And even if that would be done (e.g. hourly ),... if the valid-until time still stays long, the majority wouldn't benefit from all this. > * The security archive might want a different validity period. Sure,... as I've proposed in the beginning :) > * 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. I think this surely is rather some long term goal... it definitely would need to be configurable what should be done: - doing nothing - just shutting down services that listen on the network - loading a different set of firewall rules (perhaps such, that block all network access from the internet, but allow the services to be still reachable from the "trustworthy" intranet) - completely stopping all networking (i.e. systemctl stop network.service or something like this) - really shutting the node down (may actually be desired for some people, because a security hole could have been found in the kernel, that allows remote attacks and even bypassing netfilter) - or a mixture of this combined with perhaps a timeout of automatically trying to reach the admin via SMS, and if he doesn't take action within 20 minutes do xyz. > * Some people here have already suggested that `desktop' and `server' > configurations might want different defaults. `Laptop' probably > wants yet different defaults. I personally wouldn't see why. We've seen these fast security holes for programs affecting all of these systems... People of all of these systems may use automatic upgraders,... > 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! I think no one said your server should shut completely down... it would be enough if - in such case - network services would shut down, or strict firewall rules be enabled. So I don't think that your notebook would suddenly poweroff, just because it couldn't get the most recent repo-data. Cheers, Chris. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
