| |||||||||||||
kdelibskdelibsPosted Nov 17, 2011 16:37 UTC (Thu) by corbet (editor, #1)In reply to: Security response: how are we doing? by joey Parent article: Security response: how are we doing? Regarding kdelibs, I was working from the Debian security tracker page; perhaps it needs updating?
(Log in to post comments)
kdelibs Posted Nov 17, 2011 17:04 UTC (Thu) by joey (subscriber, #328) [Link]
Sorry, I meant to say that one of the two CVEs does not affect stable. The other, as you note, does. (In other words, rekonq is not vulnerable, but kde4libs is.)
kdelibs Posted Nov 17, 2011 17:09 UTC (Thu) by joey (subscriber, #328) [Link]
Oops, no, I was right the first time. kde4libs in stable is too old to be vulnerable. Updating the tracker.
errata corrige Posted Nov 18, 2011 18:26 UTC (Fri) by zack (subscriber, #7062) [Link]
Hi Jonathan, thanks a lot for this article. Keeping the attention level on security issues high is indeed very important for distros.
I also know that getting this kind of data right is particularly hard, given that there is a lot of internal knowledge in distros which is not always as accessible as it should be. In spite of that, you've done a more than decent job at finding security data.
But it is also good that, in the Free world, we can improve on the basis of feedback we receive, and I'm happy to see that you've already received quite a bit of it in comments. Would you considering updating the table to reflect the factual feedback you received here? AFAICT the following changes are warranted:
- the kdelibs line should be "NV" for Debian
- the rpm line should be NV for both Debian and Ubuntu; the point is not much that both distros package RPM, but rather that the vulnerability affect a feature of RPM that is anyhow unavailable in the two distros
- I think it'd also be fair to mention that the xorg vulnerability in Debian has been postponed to the next point release on purpose; the choice is of course debatable, but making an assessment and deciding to postpone is not quite the same as being lagging behind, as the current presentation seemt to imply
Depending on how you read the above data, the "none" count for Debian would go down to either 3 or 4, the most common value for the columns of your table. Considering that, I think it'd be fair to reconsider your "it is, in particular, sad" comment.
[ Disclaimer: I'm the current Debian Project Leader. As such, my point of view can't be more biased. ]
|
|||||||||||||