Two weeks ago
, this page
compared the response times of several distributors to a small set of
recent security issues. That article generated a number of comments and a
fair amount of mail from people who felt that its conclusions were
inaccurate. As before, the table shows the number of days required for each distributor to issue an update. For the purposes of this table, the clock starts when a vulnerability is disclosed, or when the first distributor alert is issued, whichever comes first. So, here is a new version of the response times table which takes those comments - and alerts issued after publication - into account:
In the above table, numbers which are underlined reflect alerts
issued after the previous version. Those which are, instead, bold
are corrections for erroneous entries published two weeks ago.
As one can see, a number of corrections were required. One might conclude
from this that your editor was being even more clueless than usual when
compiling the previous version of the table. One would probably be right,
but there is a little more to it than that. It turns out that putting
together a table like this is a hard thing to do.
The previous version stated that Fedora had not issued an advisory for
clamav. That is, in fact, true; no advisory ever came out. The clamav
package in Fedora Extras was quietly replaced, however, shortly
after the vulnerability was disclosed. In the presence of silent fixes, it
is hard for users to know if they are vulnerable or not; this is doubly
true in cases where security fixes are backported to previous releases of
the affected package. Fedora Extras does not do backporting, but it still
requires an alert administrator to know that, while clamav has been fixed,
ProFTPd in Extras remains vulnerable.
Speaking of ProFTPd, your editor had seen that package in a SUSE
distribution he had at hand, and assumed it was still distributed. That
turns out not to be the case.
Both SUSE and Gentoo claim to not be affected by the vim modeline
vulnerability because they ship versions with the modeline feature turned
off by default. Turning off a possibly insecure feature is a good thing to
do; it reflects a concern by the distributor for the security of its users.
Some of those users, however, will certainly turn the feature back on.
Others will be concerned by the fact that they are running software with a
known, unpatched vulnerability, even if that vulnerability does not directly affect them.
In such cases, it would make sense for the distributor to, at a minimum,
issue an advisory explaining the situation. Putting out a fix would be
Other corrections above reflect simple screwups on your editor's part.
The corrected table still shows some real patterns in the relative response
times for security updates. There is value in this information. As time
permits, LWN will be making changes to its security database to make the
generation of this sort of table an easier and more accurate process. But
a task which, in the presence of nice things like CVE numbers, should be
relatively straightforward is likely to require a fair amount of time (and
iterations) for the foreseeable future.
to post comments)