On Thu, 2014-10-30 at 01:29 -0400, Michael Gilbert wrote: > There is also LWN as a mechanism for independent verification. Don't they just take up the information from Debian themselves? > Although there is often more than a day long delay on that, and more > on weekends Which makes it inadequate to deal with the issue we were talking about. > it can be used as reliable indicator if has different > information than expected from the DSA mail. That is a retroactive > process, so sure it isn't a preventative measure, but when something > does differ, at least you know that the events you observed for the > prior day were suspect. I actually regularly look at LWN, but I wouldn't bother to remember which updates they've listed and whether there's anything I've missed on d-s-a or in apt. > The mail and dak install are manual and independent actions, so the > timing difference is the human in the loop, and is rarely more than a > few minutes. Maybe the two could be tied together, but someone needs > to volunteer to do that. Just FIY: I definitely wasn't criticising that mails or the data on the web may have been delayed in some cases... actually that's what I've naturally expect in most cases: First pushing the updates... and only then starting to write some prose text about it :) > > See above, both means of distributing DSAs seem not to protect against > > downgard/blocking attacks. > Why wouldn't a once per every TIME debsecan cron job not solve the > entire automation problem? I would need to look at debsecan whether it avoids the issues we have in apt. But I mean at least to me it sounds quite appealing of having it secured there (apt/aptitude). It's the central place for package management, it's what my 3rd party tools any nagios checks use. > If the problem really is the lack of a nagios plugin, then that seems > like a straightforward problem to solve, and a potentially positive > direction to focus this energy. I don't feel that this is the way to go, since it rather seems like just working around an issue... but you'd need to explain in more detail, what you actually imagine. At it still has the problem that not all people would secure themselves via that plugin. Some may use their home-brewed shell scripts that query apt and install security packages automatically, some may use existing packages for that, and so on. > I think ftpmaster said they would consider signing more often, but > they were not willing to consider reducing validity time (in case > something does go down). Well I did notice that, but two problems remain open: - if we have so many mirrors, that are that slow, then one would still need to distribute the re-signed files on a fast track. Otherwise all the people who actually choose to tighten their validity times may end up having problems every now and then. - it still leaves the broad majority which either don't care or simply doesn't know "vulnerable" So I personally (and I know that I have a more extreme security POV than most here) feel, that we should actually want that people get errors, when the master servers in Debian get down. People should somehow be notified and see... "aha, something is going on there, I may not longer get security upgrades". Now people of course fear such changes and possible breakage, but to repeat myself: giving the user a warning on what's happening, allowing him to override the validity check and accept the expired Release file isn't something that will stop the world from turning. It's not so much different to the possibility of seeing "unauthenticated" errors that came with the introduction of APT. It happens very rarely, people get an adequate warning and can deal with it. > Debian is about meritocracy. If you're unwilling to do any of this > (or to have figured) it out yourself, then there is no reason forcibly > attempt to make others do it for you. Well unless I'm appointed ftp-master, then it's probably unlikely that I can do/decide much in that are, can I? ;-) Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature