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
the
NSA 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
quite
problematic 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.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/bbf5105a59eed196079d49c1b8625...@hub.kern.lc
