Slashdot Mirror
611 Defects, 71 Vulnerabilities Found In Firefox
Danny Begonia writes, "Some folks at Klocwork examined the large and complicated code base of the popular open source browser, Firefox. Overall, Firefox is a well written and high quality piece of software. Several builds were performed on the code, culminating in the final analysis of version 1.5.0.6. The analysis resulted in 611 defects and 71 potential security vulnerabilities. The Firefox team has been given the analysis results, and they will determine if or how they will deal with the issues." What are your thoughts — do Firefox and the open source community welcome this kind of analysis?
Note that Klocwork, while definitely a good tool, does tend to produce a fair number of false positives, so it's not possible to try to compare an automated report of potential problems to a list of problems actually agreed to be a problem and actually fixed by an organization.
Static analysis tools like the one used to produce this list tend to produce lots of false positives, because they can't make as many assumptions as a programmer who knows what's going on, and they can't follow most interactions between different modules. So the headline should be "611 *possible* defects, 71 *possible* vulnerabilities" found. More likely, a small handful of those will turn out to be real (but minor) bugs, and the rest will be bogus.
It sounds like the majority of the bugs were not checking if a memory allocation failed (e.g. new returned null). In the era of seemingly limitless virtual memory -- not to mention that a failure to acquire memory is usually unrecoverable anyways -- that's (unfortunately) a completely normal development practice. Those are pretty much irrelevant bugs.
Slashdot already had an article: Firefox Analyzed for Bugs by Software, where Coverity did automated scanning. That was welcomed by the OS community, as well as by Mozilla who partnered with Coverity to incorporate this.
You seem to have forgotten that one of those leaks is actually a feature.
"Beware of he who would deny you access to information, for in his heart he dreams himself your master."
malloc() can return NULL if the allocation fails, but new never returns 0 (at least if it's complying to standard; C++ great weakness of letting you shoot yourself in the foot rears its head again). Instead, it throws a std::bad_alloc exception, which if uncaught will eventually bubble up and terminate your program noisily. (Unless you do something stupid like explicitly trapping the exception and then ignore it without handling the out of memory condition.)
This is nice because you never need to worry that a failed allocation won't cause an easily-noticed crash in a C++ program, and so can blithely new objects without checking every single one separately.
I wouldn't trust those numbers from thecounter.com or any of the other sites that depend on user agent. Opera user here and I know for a fact that most of the time I have my user agent set to MSIE 6.0 otherwise a lot of sites give me problems and won't let me load them even though they render just fine. Those same sites a lot of times will load without a problem in firefox, when will web designers stop checking the damn user agent, it is a waste of time and just pisses people off. It has been getting better but still any analysis done that relies solely on user agent is not reliable in my book. I also would really love to have a true way to find out how close that 1% for Opera is to correct because I doubt it is correct.
Hey, there is only one Return and it's not of the King, it's of the Jedi.
Even when Opera is spoofing it's user agent string the text "Opera" is still in there and anyone making a reasonable effort to identify browsers will be able to count it accordingly. Opera's spoofing doesn't hide that it's Opera, it only acts a workaround for sites that only detect a common part of the IE/Mozilla UA string and wouldn't do anything if one of those aren't found.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
I don't think developers tell you to try the standard diagnostic. That's what end-users wrote in the MozillaZine Knowledge Base.
Developers will ask you if the problem happens with a new profile. If it doesn't, that means something different in the original profile triggers the problem. If someone can discover what that difference is, then the bug in Firefox can be found and fixed. It's not an excuse to avoid fixing a problem. It's troubleshooting what the problem is so it can be fixed.
What a fool believes, he sees, no wise man has the power to reason away.
How about the bug I constantly get where copy/paste/shift-end/shift-home quits working in text boxes much like this slashdot submission form on a random basis? (Which I, ironically, just encoutenered as I popped to a different window to search for the bug...)
Sometimes it appears to be a selection issue and goes away when I change browser windows, other times I have to completely kill all instances of firefox to get it working again...
Running on Windows Server 2003, default theme, no extensions.
This same (or a similar) bug has cropped up in various releases since early Mozilla betas.
Note: a quick search for this bug indicates it may have been fixed.
Alas, I'm running 1.0.5.6 and don't appear to have any spyware on this machine!
A final thought: Don't take this to mean I dislike Firefox, or the dev team as a whole, I love the fact that I can browse with Firefox and not have to constantly worry that my computer will be compromised by some ActiveX content I don't even want. Further I greatly respect the whole mozilla team and their efforts. However, Firefox is by no means perfect, merely the (far) lesser of two evils.
I don't even use the extension. Just go to about:config and set a string property called general.useragent.override containing the desired useragent text.