var x, y;
img = getImage("placeholder");
x = getImagePageLeft(img);
y = getImagePageTop(img);
There are currently, 22 guest(s) and 2 member(s) that are online.
You are Anonymous user. You can register for free by clicking here.
Debian Has Slow Security Updates? Contributed by Anonymous on Tuesday, January 15 @ 05:16:06 GMT
Some comments on the Linux Today story about the recent glibc security update challenged my perception that Debian is very responsive to security problems in core packages. Basically, they say that this vulnerability was reported on December 14th. Has it really taken one month to deliver a core glibc update?
This brings up a larger issue regarding security for me. I regularly run Nessus against our Deb boxes and see reports about vulnerabilities in OpenSSH and other packages. I was always under the assumption that the bug fixes were back ported to the stable version used in Potato and that Nessus was detecting the version of the package, not the existance of a real vulnerability. If I was wrong about Deb having the fastest security updates out of the shoot, maybe I am wrong about other assumptions. Can anyone give me a definitive answer?
I have always considered the slow moving profile of the stable tree one of the most stable and secure versions of Linux simply because of the care that is taken in the security updates and application versions. Am I being blinded by my love of apt-get or is there nothing here but FUD?
DanielS: Both myself and Martin "Joey" Schulze, as it turns out, sent emails to LWN to clarify the reasoning behind this. glibc is obviously both a huge and critical package, and this hinders the speed of getting updates in. m68k and arm are possibly the two slowest architectures in Debian today, and they were both released with potato, thus glibc had to be built on both of those before the DSA could be released - ever tried to build glibc on an m68k? Also, the package had to be thoroughly tested, as it is arguably the most critical package.
Joy: as for Nessus, all of the checks that merely compare the reported software version against a known vulnerable version are going to be flawed for Debian stable. Arguably, any checks that rely merely on the reported version string are pretty lame.