Links to bug reporting techniques, tips and tools
Jonathan Lange reminds us via Focus Shift that the only measure of code quality is WTFs per minute:
Actually, this reminds me of something I heard a preacher say, “before I give a sermon, I go through it, find everything clever, and take it out” (I paraphrase, not having a reference on hand).
In as much as sermons and code should both be ego-free communications of ideas, I think this is sound advice for hackers.
Popularity: 43% [?]
The 2008 random number weakness in Debian (Ubuntu etc) versions of OpenSSL resulted in an article by Jake Edge for LWN: Debian, OpenSSL, and a lack of cooperation, covering the responsibilities of upstream and packagers:
It is in the best interests of everyone, distributions, projects, and users, for changes made downstream to make their way back upstream. In order for that to work, there must be a commitment by downstream entities—typically distributions, but sometimes users—to push their changes upstream. By the same token, projects must actively encourage that kind of activity by helping patch proposals and proposers along. First and foremost, of course, it must be absolutely clear where such communications should take place.
Popularity: 40% [?]
Sebastian Kuegler has a post on releasing KDE 4, and mentions briefly how the bug tracking tool could be used to clarify the release process:
What we can do to make it easier for vendors to ship the next version of our software is making it clear what needs to be done before a release. That would mean: “Here’s a list with what the next release will look like, if you want to make it happen earlier, help us hacking” This could be as easy as recording this in bugzilla, marking it as “showstopper” or “required for x.y.z” and then make the query showing those entries easily accessible through, for example, a direct link.
Popularity: 83% [?]
Terence M. Colligan writes:
Although I thought I understood the importance of quality, and took pride in the quality of the software we produced, I never believed that delivering defect-free software was possible. After all, everyone knows that all software has lots of bugs, right?
Well, no, not necessarily! Certainly, most experiences with today’s software quality are not encouraging. Although few people can name even one piece of software which they use that has no bugs, defect-free software is possible to create. We know it is possible, because we’re doing it.
It started with a single engineer. This engineer was consistently producing work with a defect rate more than one hundred times smaller than our other engineers. She has done so for us for over three years now. During the same time, she has produced three to five times as much code as any other engineer.
I found this so exciting that I determined to find out how she did it, and to see if we could teach our other engineers to achieve the same quality results.
Via James Gregory, Defect-free code.
Popularity: 86% [?]
James Gregory reviews how to check for resource pressure bugs.
A quick one for today, sparked by recent events at work. It can pretty much be summed up in this even quicker question: do you know what your program does when it’s out of resources? Out of RAM, out of disk-space, out of address-space, out of time? Computers are indeed powerful beasts these days, and there’s a bunch of people who would like you to believe that they are effectively infinitely powerful, but observing your code working with limited resources, even if those limitations are artificially imposed, can tell you a lot of things you mightn’t have known previously.
Popularity: 74% [?]
Scott Berkun’s Project Manager clinic discussion group had a look at the politics of bug fixing in September 2005:
I quickly realized that my team wasn’t prioritizing for itself – but was prioritizing bugs around management and other perceptions of how other people in the organization would *force* us to prioritize bugs. So in essence my development team wanted to make pre-emptive political choices when it came to bug fixing. Any advice for making this process less frustrating?
Responses review the standard way to prioritise bug fixes.
Popularity: 76% [?]
Scott Berkun, author of The Art of Project Management, has a series of articles on deciding which bugs to fix:
He argues that:
Here is the golden rule of organizing bugs: fix bugs in the order most likely to result in success. Sounds obvious, right? Wrong. I’d bet that more than half of the buggy and unreliable software you’ve ever used was that way not because the developers didn’t have time to make it better; they simply fixed the wrong bugs. Wanting to fix the right bugs and knowing how to do it are two different things.
He describes four approaches to bug prioritising:
Popularity: 63% [?]
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:
- 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.
- 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: 63% [?]
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% [?]
Rick Schaut describes the process of finding a bug in Word 6 multiple undo that caused a file descriptor leak.
Popularity: 62% [?]
Posts in this section are all about avoiding and fixing bugs.
Popularity: 38% [?]
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% [?]
Yuriy Brun and Michael D. Ernst are publishing a paper in ICSE’04, Proceedings of the 26th International Conference on Software Engineering, (Edinburgh, Scotland), May 26-28, 2004. on Finding latent code errors via machine learning over program executions.
Popularity: 44% [?]
The mod_perl site has a very comprehensive guide to debugging mod_perl applications.
Popularity: 44% [?]
Michael Bacarella’s Peon’s Guide To Secure System Development lays out basic guidelines for developing secure software including validating user input, and (controversially) avoiding C/C++.
David A. Wheeler has made an entire book on the subject of secure development, the Secure Programming for Linux and Unix HOWTO, available online. (Via Steve Kemp.)
Popularity: 43% [?]
The Sydney Linux Users Group’s Debian Special Interest Group (SLUG DebSIG — phew!) has a number of Debian RC Bug Squish days coming up, the first on 13th March 2004.
Popularity: 43% [?]
Malcolm suggests that bug hunters should adopt some of the same face saving techniques described by The Old New Thing that product support people use to avoid embarrassing their customers with obvious questions.
Popularity: 43% [?]
