The latest update to Firefox has been pushed out to users via an automatic update. This one was rushed through, mainly to fix the vulnerability used to win the 2009 CanSecWest Pwn2Own contest (MFSA 2009-13: Arbitrary code execution through XUL <tree> element).
In addition it contains a fix to a vulnerability (MFSA 2009-12: XSL Transformation vulnerability) that was first reported in July 2008, re-reported in October, patched in November, and then forgotten until it was re-reported on March 25th. So why did it take 8 months to get a fix out for this serious problem?
More: Why this bug fell through the cracks >
Going through the comments, it took 3 months for the bug report to make it from the Ubuntu bug tracker to the Mozilla tracker. When a patch was made in November, it was reviewed by a committer 11 days later but was rejected because it didn't quite meet some stylistic concerns in the test case. The patch was resubmitted the next day, but then the committer neglected to follow up on it.
To prevent this kind of thing from happening again, Jeff Walden has started a discussion thread in the mozilla.governance forum. He writes:
A bug was filed, a patch was posted, but it didn't get in the tree until "too late" (for a not-worst-case-scenario definition of the phrase, but still way too close to it for comfort). Some questions to ponder:
- When did we fail to keep things moving along?
- How do we make the process clearer and more discoverable for new hands?
- What documentation needs to be modified to help that clarification?
- Are there any changes we should make to the super-review process (or the review process) to ensure patches don't fall through the cracks?
After some discussion of the root causes, Brendan Eich chimed in with this observation:
Why were responses slow, given the severity of the bug? I think because the severity was not appreciated. Free Memory Read when calling through a vtable pointer is exploitable. This may not be fully appreciated by all committers and drivers.
I think this discussion is a great example of the transparency and continuous improvement typical of many great open source projects. Mistakes happen. The only way to reduce them is to notice them and resolve to learn from them and do better. Open source and open bug tracking enables that at a level not possible with conventional proprietary software techniques.
More: Firefox 3 release history >
Mozilla has been updating Firefox 3 approximately once a month since its release in June of last year. Here’s a list of all the updates so far:
- v3.0.8, released March 27, 2009
- v3.0.7, released March 4, 2009
- v3.0.6, released February 3, 2009
- v3.0.5, released December 16, 2008
- v3.0.4, released November 12, 2008
- v3.0.3, released September 26, 2008
- v3.0.2, released September 23, 2008
- v3.0.1, released July 16, 2008
- v3.0, released June 17, 2008