On 2014-06-23 17:33, Christoph Anton Mitterer wrote:
Well I just think that most of the time, our Security Team does some very great job (if not hiding away issues o.O) and fixes are available in Debian very shortly after a fix is available. These guys put a lot effort into that, but their quick response is useless if those periods are so long.It gives an attacker that can MitM (and we must expect that not only theNSA can do this) 7-10 days (!!!) to conceal updates from a system and exploit the security holes they fix.Especially since many server systems update automatically, this is quiteproblematic IMHO.
And how many of these "automatic" updates require a followup on critical issues? Sure, the library on disk is updated, but are the servers restarted[1]? Are the servers rebooted for that root exploit fixed by an update to the kernel package[2]?
Just as I assume that a competent admin will figure out these problems for her services, I assume them to read advisories. And if you read a critical one and you can't find it on the mirrors upon apt-get upgrade something is fishy and someone will be bound to investigate.
Kind regards Philipp Kern[1] I'm aware that certain libraries do restart services affected by the upgrade, but there's no generic framework for this. [2] I'm aware that some people like DSA use Nagios checks or cron jobs to ensure that the running kernel image matches the on-disk image or alert otherwise.