Survey responses

What are some of the other options that you're considering using to fill the space and time currently being used by vulnerability reporting?

The last question needs a "Don't care" option, probably spelt "Whatever".

Personally I rarely read the security alerts themselves; I do sometimes read the articles published in the security section. But, while I don't personally find this service useful, I'm sure some people do; I would not mind it being kept if it was useful to others - those such as myself who are not interested will just skip over it.

You're right that parsing various distros' security announce lists is a PITA.

That's why I'm glad that you do it once, for all of us, rather than
each of us having to do it ourselves in our heads :-)

I'm subscribed to the distros I use most, but having a single daily
RSS digest is much faster to read, and can alert me about super bad
things that 1) haven't yet been fixed in my distros; or 2) affect
other distros that I don't use much, but some of my customers do.

(Sometimes it also cheers me up by schadenfreude: "har har, RoR is
still a bag of swiss cheese, glad I'm not running it.")

The occasional articles explaining what's happening are worth a LOT, and to generate those you need to be looking at a lot of the vulnerabilities.

But the detailed 'new vulnerabilities' section has grown so large that I no longer do more than skim it as I go down the 'one big page' view.

I run different distributions - and different sets of apps - between my work, home and hosted machines.

To be honest, that would mean subscribing to a lot of security mailing lists. The LWN daily security summary is therefore a valuable timesaver for me.

Not so valuable that I'd cancel my subscription - but valuable enough that I would grumble a bit.

It's a pity, from what you've said, that there isn't a standard "vulnerability report summary template" that people could be encouraged to use. I suppose many would bicker over what should/could be included - but the LWN summmaries would be a good starting point.

Thank you for providing them, whatever you choose to do.

Frankly, I love the *reporting* on security vulnerabilities. The background and detail.

The raw listing of "holes in X" is wasted on me. I have automated jobs that handle checking and validating updates.

The discussions of issues are useful on several fronts. My understanding of specific significant problems allows me to realize that I should do something more about them sometimes than just update. My understanding of *classes* of security issues grows so that I can better endeavor not to create such bugs myself, and deploy systems that are more robust.

The big list of what's broken recently is too much information for me to reasonably process, and I'm really not very interested. If my distribution can't provide timely updates to these problems there's no way I'm going to succeed in handling the problem myself.

Grouping security advisories by package or project rather than by distro would be more helpful to me.

I like the service but I would be OK with it going away, if that were the thing.

Well, I'm basically just a distro "consumer" so I completely rely on my distro's security team to do a good job. If I were an admin, I would probably spend much more thought on this and I guess there are quite some admins among LWN readers who appreciate the work you're doing :)

It's good that LWN's weekly edition includes security bulletins in such a prominent place. It's a sobering reminder to all of us that we need to do much better in this area.

[Alternate way of commenting on advisories suggestion]
Pick the advisories you think are most critical or important. Elaborate on their origin in the source code and teach me (and the developpers) how to avoid them in the future.

(In case you did not understand, I do not believe much in security alerts as a way of improving operational security: too many, too fast, and no way to reboot that important database. But I believe a lot in them as a potential source of information for improving the security of our programs in the long term - and in closed source as a last-resort mean for forcing uncooperative manufacturers to correct their errors.)

My 2p -

I have a passing interest in the vulnerability announcements, some are irrelevant to me, others are interesting (Web stuff/perhaps kernel related ones/Java/RoR etc) and some are useful/affect me (e.g. PHP, Apache, MySQL and so on).

What would make it more valuable to me would be e.g. tagging them by product/project and/or language - so I could e.g. visit http://lwn.net/security/something/php or http://lwn.net/security/something/apache

David.

It would be more useful not to have detailed listings for all distros but a list of distros which fixed the problem. And most important to me, an easier way to get information on the actual problem and fix or a remark "no details published".

When I was creating the old rPath advisories, I offered to format them to LWN's specification for sending to LWN to make your life easier.

Where you already have a parser, great; but I think you are in a position to post some view of your internal schema and a spec for a representation that you can parse and say, "we're not adding you to this valuable resource unless you provide data to us in this format".

As far as I know, no one else is cross-referencing vulnerabilities this way.

If you are overburdened and need to make changes, I would hope that you would first decide to do less work trying to cross-reference the advisories but still collect and publish the data centrally.

As with the rest of LWN, the (considerable) value I get is in the analysis you do. If I need to know what vulnerabilities have just been fixed I get that from the distro's announcement list.

On the other hand, the deeper understanding of what happened to cause a vulnerability, or a class of vulnerabilities which your longer articles provide is excellent.

The commentary and articles on security are interesting, and I'd like to see them stay as they are. With the list of advisories, I'd be just as happy if there was a one-per-row table of them with links to a separate RSS'd page with details.

Usually, all I care about is package, platforms, severity, and whether there's a fix. My usual reading pattern for the security page is to scan down it seeing if there's anything in the list that potentially affects me, and if nothing twigs I move on.

Since my sysadmin duties are lightweight and mostly self-inflicted (and mostly not internet-facing), the list of vulnerabilities that can cause me grief is relatively short. Practically speaking, if openssh/openssl, openvpn, firefox and nginx aren't on the list, I can usually just move on.

I do like having the details there when I want or need them, though.

Descriptions of vulnerabilities, how they got there, and how they can be exploited, is really interesting. Don't throw the possibility of that baby out with the "X has a bug and N different distributions have fixed it" bathwater.

Gerv

I read the (work) daily Security Advisories article nearly every day. I maintain systems running 3 different distros and I prefer to understand a bit what the updates are all about before applying them.

The deep analysis articles are the most useful ones, but I understand that it is not feasible to write an ever growing amount of them (nor would it be feasible to read all of them)

Rationally thinking I could probably just subscribe to the security lists of those 3 distros. But in reality I subscribe to too many lists already, don't enjoy to read email and don't do it very well, also my RSS reading could be organized better. However, I like to check out lwn (nearly) every day and just do it much better than those other channels. Admittedly not the best argument to waste resources, but then I also pay for lwn and not for mailing lists.

I'm not sure whether I have used the security database before. Google tends to give good hits on lwn (at least in my personal search bubble), so I might have without being really aware of it. Now that I learned about it I might occasionally use it also in future. But on the other side I guess all distro security mailing lists are archived and Google will find it if you search for something particular.

I guess your own DB allows you to make cross distro analysis e.g. about response (=fix) times (I remember one such article in the past). But if maintaining the DB requires substantial manual labor (don't know how assuming that you publish the daily article anyway), personally I could live without the DB.

The vulnerability database would be more useful if it were indexed by package as well and more arbitrarily searchable. Maybe a matrix view of versions of a software with which CVEs are fixed in which version and which are outstanding along with which are backported and which are missing from the distros repositories. Or maybe a tool to import a CSV of a machines software inventory and output a list of what's patched and what isn't. Maybe a table of which CVEs are outstanding for each distribution on every date.

Or maybe this all would be better handled by some separate tool or separate organization outside of LWN, if it is taking too much time and not providing enough value.

I do typically skim the vulnerability reports to see the actual underlying security holes, because I occasionally find the description of the security problem itself interesting. However, I don't see much value in the aggregation of cross-distro vulnerability information; if I want to know about security issues in my distro of choice, I'll subscribe to their security announcement list, and do regular updates from their security repository. If it saves time to drop the aggregation and correlation, and just keep the bits about security holes in the underlying software, that seems like a feature.

For the security updates, I'd prefer that you highlighted upstream problems/fixes, rather than each of six or seven distros' interpretation of essentially then same thing. (That's probably because I don't use one of those 6-7 distros, and just care about whether I need to worry about my installed version of such-and-such a package.)

I wonder whether something like:

Foo: buffer overflow in XYZ parsing [RHEL5, RHEL6, SLES10, ...]

where the things in brackets are links to the relevant distro advisories might be clearer?

"How useful is the LWN vulnerability database to you?" is missing an option for "What vulnerability database?"

The daily security advisories are certainly useful. But they could be a little more concise, group families of distos together, or at least don't repeat rebuild distros (like CentOS, Scientific Linux, Oracle, etc.) if the upstream Red Hat distro already did an advisory earlier that week. It might even be more informative to only mention if the rebuilds don't follow upstream or have a long delay providing the same fixes.

A direct copy and paste of the various -security-announce mailing list subjects (with links to the announcements themselves) would be quite sufficient. You wouldn't have to do hardly any work and yet it would still be quite informative.

Rather than the detailed list of new vulnerabilities, I'd rather you'd post a little editorial summary in a paragraph of two. Like: "Watch out for this vulnerability in apache if you use the stock config from Debian, other than that there are a few kernel local privilege scalation vulns. worth keeping an eye on. As for the latest round of Java vulnerabilities, most major distributors already have updates available". Kinda like a weather report.

I nevertheless find the reporting and analysys on the security page to be very good and it would be great if it could be even expanded now that you wouldn't need to dedicate so much time to listing all the vulns. and advisories in detail.

My only complaint is that sometimes advisories contain no useful information that one can act upon. In fact, sometimes the vulnerability description is literally "unspecified vulnerability", and often the CVE links only point to a page mentioning that a CVE number has been reserved. Must I panic and immediately delete the affected software from my computers with prejudice? Or should I just ignore it and hope it is not something that affects me? I don't know if such advisories are useful for some people, but I would rather not see them until they contain information I can act upon.

To me, it’s often more important to see what software has vulnerabilities, than, what distro has updated their software.

So, the current form is somewhat useless (too hard to filter out the really – to me – important information) but still better as nothing because it’s all in one place, somewhat.

(Background: vulnerabilities in software X usually stretch across distros, they might just not have noticed yet. Most environments are heterogenous, anyway. I’m able to patch and recompile myself, if needed.)

I like the terse overviews: Redhat has patched this and that, Debian something else, and Ubuntu those other somethings.

And I also like the security reporting, like the article on Recent Java vulnerabilities.

But the list of advisories is IMHO useless. Because there are now so many that even CVE had to change to more than 4 digits per year.

It could be interesting maybe to have the vulnerability database published as json or yaml. And maybe suggest distributions to publish their advisories in the same format so that import can be more automated.

With such a database someone could create tools to do things like sending an email for each advisory for a software he has installed on his computer, or for software available in his custom packages repository.

I currently use the security page to check if there are any vulnerabilities that affect any of the systems I am responsible for, and this is one of the main reasons we have an enterprise subscription.

I would like to have some way of more efficiently getting the security and vulnerability information that is relevant, and maybe a more efficient way than is currently possible.

For the "security alerts database" I would have liked:
* Possibility of date search, to list all vulnerabilites for a selected date range, or from a certain date up to current date.
* In the case of a search I would like to see the whole result list, without having to use a next link.
* Possibility of listing with a oneliner description of the fix/vulnerability, but that is probably too much work to extract.
* The possibility to limit the security listing to certain packages, or to exclude certain packages, to make the listing more relevant for my installations.

For the "security vulnerabilities database" I would have liked:
* Possibility of date search, to list all vulnerabilites for a selected date range, or from a certain date up to current date.
* In the case of a search I would like to see the whole result list, without having to use a next link.
* The possibility to limit the security listing to certain packages, or to exclude certain packages, to make the listing more relevant for my installations.
* The possibility to list all vulnerabilities where a chosen distribution has not provided any fixes yet.

What I miss in the security is a cumulative total. 2-3 times a year I'd very much like to see a text like this:

"There are 256 vulnerabilities in our DB for the report period (that's 18 more than in the previous period). The major bug in Iroquois web server has hit most sites. BlueCap distribution was the first to fix it.

Overall Bruceian distribution was the most active in fixing security bugs — they fixed all 256 vulnerabilities and the mean time to react to a vulnerability report is only 18 hours. The second best was MarchHare — their numbers are 248 and 27.5 hours, respectively."

Hope I explained my wishes.