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% [?]

This entry was posted on Thursday, October 27th, 2005 at 9:01 pm and is filed under Security bug fixes.