Software bugs

There’s quite a lot of guidelines out there on how to report a security vulnerability in a responsible way as a third party, but not so many on how to report and publicise a fix if you are a software author. (And recall, many software authors are part-time hobbyists, not corporations bankrolling a security team.)

Karl Fogel’s Producing Open Source Software: How to Run a Successful Free Software Project book has some guidelines:

Most open source projects have settled on approximately the same set of steps to handle this conflict between openness and secrecy, based on the these basic guidelines:

1. Don’t talk about the bug publicly until a fix is available; then supply the fix at exactly the same moment you announce the bug.
2. Come up with that fix as fast as you can—especially if someone outside the project reported the bug, because then you know there’s at least one person outside the project who is able to exploit the vulnerability.

He goes on to detail the process of being assigned a CAN/CVE number, notifying important or particularly vulernable vendors or customers, and making a public announcement.

Popularity: 64% [?]

Joey Hess describes the trouble for distros trying to provide security updates for Mozilla:

That’s right, this bug, which is for a security hole that was fixed two weeks ago, is not being dislosed until apparently, August 1st. Same is true for several others of the holes fixed in recent versions. That’s two weeks for distibutions that have to backport these fixes to race against black hats to see who can track down the hole in all the other changes in the new mozilla release, and respectively fix and exploit it.

And so Ubuntu has decided to backport the new mozilla versions into their releases instead of backporting fixes, while Debian stable has decided to bow out of the race. Both understandable decisions in their own contexts.

Popularity: 64% [?]

Ben Goodger argues for the use of Mozilla binaries rather than vendor binaries because binaries have security patches applied earlier:

If security is important to you, this demonstration should show that browsers that are redistributions of the official Mozilla releases are never going to give you security updates as quickly as Mozilla will itself for its supported products.

.

Christopher Aillon criticises this as bad practice:

Other projects make sure that the vendors know of a security vulnerability, supply the patch and new tarball (if applicable, which it is in mozilla.org’s case), give a brief period of time for the vendors to catch up, and then do a synchronous release with them at a planned time.

(via Slashdot)

Popularity: 62% [?]

Havoc Pennington describes the coordinated release process for security bugs:

The simplest thing is to quietly notify any of the major Linux or BSD distributions and let them take it from there… Once you notify someone, wait to hear back. The upstream maintainer would normally announce the vulnerability and commit patches to CVS at the same coordinated time that vendors post packages. If you patch in CVS before anyone is ready with packages, your users are vulnerable during the gap (and generally unhappy about it). Worse, by committing a patch to CVS you’re doing something that a black hat could notice, but most sysadmins will not notice.

Popularity: 100% [?]

The Open Source Vulnerability Database is an independent vulnerability database created by the security community. It is available to individuals and corporations without charge.

They are currently looking for security professionals to help maintain the database.

(Found through Raven.)

Popularity: 83% [?]