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?
do Firefox and the open source community welcome this kind of analysis?
Obviously, yes. Otherwise, open source would be closed-source.
It seems mainly the problems were to do with memory leaks. Which having seen firefox eat 700mb of ram doesnt surprise me....As long as these probs get fixed i cant complain...Doning this kinda of analysis is much easier with the source code i imagine.
And nobody actually likes hearing the negative parts of them, but the wise will consider them and work on resolving the problems.
God I hope so. What on earth is the advantage of open source security if they don't get this kind of analysis?
TW
Seriously, any free testing is better than none. Especially when they point out the problems explicitly and hand them to you. As a developer, you're then given one last chance to fix your product -- if these even need to be fixed. I would expect things like the 134 memory leaks to be fixed and fixed fast. I've known Firefox to occasionally go on a memory splurge at my computer's expense and have expected this to be the problem. As far as some of these other problems that are mild security issues, they might not need to fix them at all.
Even the article admits that a lot of these "issues" are trivial to fix: Sounds like a two week job of an intern to me. Checking for null and handling it after memory allocation could probably be a cut and paste job. If they mention the line numbers and files, there's your fix.
Either way, this is the beauty of open source software, anyone can go in and do this. Now, if you found bugs in a proprietary program from some company and sent them a breakdown of problems, you'd get one of two responses. 1) No response and 2) A charge that you are reverse engineering their product and in violation of many anti-piracy laws. If the company still didn't address the issues and you published the bugs, then you're nothing but a software terrorist.
So let's kick back and watch open source at its best! No software is perfect, but it will be enjoyable to know that a process like this can occur -- with the end result being a better free product on my machine!
My work here is dung.
Why wouldn't people like the fact that an independant group audited the code?
At least with open source, you can do that. And, giving the report directly to the Mozilla people means that they know the issues are there and can address them.
Better than security through obscurity where only the one who found the exploit knows it's there.
Cheers
Lost at C:>. Found at C.
as a user, I value this kind of criticism - it's better out in the open where the devs are pressured to do something about it, than behind close doors where those of malicious intent can go about their nefarious business unhindered.
34486853790
Connection too slow for X forwarding? Try "ssh -CX user@host"
Closed-source software companies are paranoid about this sort of thing. They are often openly hostile, to the point of suing anybody who does this sort of analysis.
Insisting on "correct" English is like saying that there is only one, definitive recipe for chili.
Right after they hired that Microsoft Security expert nevertheless!
> What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
No, they're going to sweep this under the rug and disappear anyone else who audits their code. What the fuck do you think?
Found 700 bugs in a quick analysis? Wow, I want those people debugging my sourceforge projects too!!! Someone care to explain this FUD, I'm too lazy to RTFA.
Seriously ... this basically is free work in finding bugs some user with less well-meant ambitions could have found and not reported.
Screw the FSM - Real geeks believe in the Invisible Pink Unicorn
"What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?"
/question to this story.
I dont' understand how there can possibly be a "No we don't want that" argument. Me thinks someone tried to hard to add an interesting comment
--------========+++Dont Feed The Lab Techs+++========--------
Does Open Source encourage this kind of analysis and input? Absolutely. I'll take it two steps further. As of now, the Firefox team can:
1. Ignore the data.
2. Use the data to make a better product.
3. Look at the data, decide what is a true security issue/bug or not, and proceed on.
And, then there's also the option for the users:
1. Use Firefox as it is.
2. Make their own version.
The very idea of Open Source would, if there is a truly serious bug/security flaw that Firefox ignores, allow another group of people to fix the issue and release their own version - which could compete and even surplant the current Firefox version with the user base should people decide that's what they want.
So, without appearing rude, I would state that the question is a silly one. Yes, Open Source encourages this kind of analysis of all kinds. It just has a built in process that allows action to be taken - even if the primary code developer does not want to.
Of course, this is all just my opinion. I could be wrong.
52 Weeks, 52 Religions with John Hummel
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.
Of course they do. Closed source companies say "what's my profit motivation for fixing these, and how much is it going to cost me to do it, and what are the costs of not doing it". Open source projects (usually) don't operate under those restrictions, so there's little downside to having issues pointed out.
I don't see why the poster said "if" the Firefox team would use this report. They has been highly responsive in the past. I fully expect the Firefox team to analyize the results and fix the problems. Their bread and butter is to make it a stable and secure browser. To simply ignore these issues would be going against what they stand for.
That's sooo Osama bin Laden.
You have to know where the holes are to fix them. I can't see this being perceived as anything but good (improvements for Firefox now lie ahead) by reasonable members of the community. Sure, no one likes it when bugs are found in their code, but I would hope that most programmers genuinely want their code base to improve.
This is a great opportunity unless you are a PHB and/or marketing hack to use it as spin. I would guess the FireFox developers welcome the specifics and can then analyze and implement fixes to the problems found.
It does make one wonder about closed source applications where the independent eyes are not allowed. I, for one, would rather use an application that has been reviewed by independent sources. If browsers weren't free, I would pay for FireFox & Opera.
"Saying that Linux is inferior to Windows because more people use Windows is like saying that all restaurants are inferi
FTA:
Only someone with in-depth knowledge and background of the Firefox code could judge the danger of a particular security vulnerability; therefore, I have not included more detailed information of these security vulnerabilities that could lead to the spreading of unfounded rumours of potential exploits. However, for those interested, I've provided more details of the defects below.
Well here come the rumors. All software has issues, some more than others, but firefox is still less vulnerable than IE at present, and will most likley remain so. Moreover, its open source, so we can all find and fix if we have the skills to do so, and the Firefox Dev team can't hide from them.
I assume the IE codebase will be tested next for balance, and then Opera and Safari for interenst..
So how long till this gets blown out of all proportion?
Is that the closed-source people will jump all over the report and say "see how bad Firefox is?", when the reality is that a similar analysis of their browser would likely (I assume) turn up similar, if not worse, defect levels; of course, since the analysis can't be done, they get the opportunity to bad-mouth the open-source effort.
Hey, if it makes them fix the copy/paste bug, it's all good by me.
-----
...I recently wrote an article for Better Software (details here) showing the duplicated code and some other static analysis-type problems that PMD turned up in two fairly popular open source Java apps - Azureus and Columba. Both these programs are excellent open source apps, but both also had a number of places that could be improved.
This is kind of a Slashdot permathread, but anyhow, static code analysis is not a replacement for smart people also looking at the code. Rather, it augments folks' efforts and provides a safety net to catch little problems that can slip through. A duplicated code detector is especially useful because it can scan a massive codebase and help pick out chunks of code that can be refactored away. This reduces the lines of code, eliminates the possibility of duplicate bugs, and is great fun.
The Army reading list
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.
Obviously, yes. Otherwise, open source would be closed-source.
The numbers look large given that Firefox is supposed to be the superior browser, but can you imagine what those same numbers would look like for IE? Think Gates & Co. would care to give up the source code to do a head-to-head comparison? I'll bet the folks in Redmond are looking at these numbers and wondering just how to get IE's numbers that low.
GetOuttaMySpace - The Anti-Social Network
Firefox just crashed while I was reading this article.
120 characters for a sig? That's bloody useless.
I wish they would have done a comparison with IE. Of course IE being closed-source they can't, but now all the IE fanboys are going to come out of the woodwork.
At first I thought "Great, another FUD piece overblowing what are probably trivial issues."
The I RTFA and saw that it was an honest report of errors given in a straightforward and clear manner.
And like other posters have mention, none of them sound that life-threatening.
I'm sure some Microsofties are going to be spinning this wicked for the next couple of months however.
My twitter
OK, I'll jump for your obvious trolling bait. But of course opensource solutions would welcome a reports such as this.
Its the closed source solutions providers that would cringe, pull hair, and writhe on the ground if it was ever published the results ran against their code.
(Oh, and they'd trundle out their FUD machines full force instead of actually fixing the identified issues)
Wherever you go... There you are. B.B.
What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
Not getting this kind of analysis isn't going to stop the bad guys from running them.
I did a lab last semester where two computers where set up, one running IE, one Running Firefox. I attempted to hack both of them using the BackTrack distro... a linux distrobution with a ton of tools and hacks to test vunerubilities. The conclusion? It took me less than 5min to hack the Box using IE through the browser. Took me 4 days for Firefox.
... is that if there are ever bugs found, it's nothing to blame them on the guy next to you instead of yourself. 'Open Source' implies collective code ownership, after all.
Seriously, though, memory leaks and null-pointer references are pretty trivial. They can have this fixed by 2.0 easy.
"Can't last more than 20 minutes on Myspace" bug?
Yeah, that's right. I just admitted to using Myspace for more than 20 minutes at a time.
Blessed be he who reads this post, Cursed be he who tells my boss.
Ive been in the QA field since 97.... no matter the complexity of the application, there are countless bugs, defects, etc.... in fact development in most cases welcomes the more found, hence the more fixed. There is a book on Amazon called the Art of Software Testing (http://www.amazon.com/Art-Software-Testing-Second /dp/0471469122/sr=8-1/qid=1157645733/ref=pd_bbs_1/ 103-3570097-7021412?ie=UTF8&s=books), which states no matter how many defects are found, it's probably not even half of what could be found with plenty of people testing an application. With an application like a browser where millions of users become testers of sort, this is bound to happen. So this doesnt bother me, as hopefully one would think the vulnerabilities and major issues will be fixed....
In your post, you conflate software bugs with security vulnerabilities. These two things are not equivalent; at best, security vulnerabilities are a subset of software bugs.
my pet machine
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.
The biggest push I've heard given to corps over the years is not that OSS can be modified, enhanced, integrated, or reused, but that it can be inspected, reviewed, and fixed.
If there is anyone working in OSS who doesn't appreciate receiving such an analysis of potential bugs, then they shouldn't be programming anywhere. Whether for fun or profit, fixing the bugs and adding features is what the "job" is.
I do not fail; I succeed at finding out what does not work.
Well they certainly don't appreciate being reminded that they still don't support the disable-output-escaping feature of XSLT..
http://bugzilla.mozilla.org/show_bug.cgi?id=98168
..Jeff Keegan
seven syllables explain TiVo: kee gan dot org slash ti vo
I remember back when it was before 1.0, Firefox was quick and small. But it seems to be on the path of many pieces of bloatware. It just seems to get bigger and bigger, and slower and slower. Back then it was a tiny little app, now its almost 50MB expanded on my machine. Cripes. I think Firefox might be in need of a remake and return to its roots.
One of the top theoretical benefits of open source is the "Many eyes" method of bug spotting. And Klocwork provides an "electronic" eye. (I am imagining the Six Million Dollar Man sound effect here.)
Have you Meta Moderated t
700 defects sounds like a lot, but most were probably not done by manually examining the code.
:-)
More likely, it was a codebase scanner that checked for problems, such as memory leaks, double frees, stack issues, etc.
The real question is, was the scanner likewise scanned for problems?
I think this sort of stuff is great because the old practical advice of "getting an extra set of eyes" holds true, especially in technology. The tone of the report is professional instead of condesending, as so often I've seen on mailing lists when someone 'reviews' another's code. I imagine that this report will be well received by the Mozilla community at large. Even though the types of errors referenced in the report are common, it is still a great example of free software / open source philosophy working.
Comment removed based on user account deletion
I love criticism, it makes me stronger.
Should also make your software stronger
--
Now where did I put my brain...
-- I am the NRA, enough said...
What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
I would think the answer would be "yes, absolutely so."
Personally I've always thought people should make more extensive use of these kinds of automated code
analysis tools. When there are classes of problems that can be found using fairly mechanical means that
can be programmatically driven, it just makes sense to do so, IMO.
// TODO: Insert Cool Sig
"do Firefox and the open source community welcome this kind of analysis?" I think there should be people allowed to test the software for vulnerabilites and security risks because it lets the developers know about them sooner. In the end it should help this browser become more efficient and stable. I use Firefox on a regular basis. I love it. I also love the tabbed browsing as it makes my windows so much more managable. Before I had about 6 or 7 different browsers open before I used tabs. Keep up the great work firefox team!
It's great that the Firefox codebase has been scanned, but surely Firefox also depends on other open-source libraries? If these are not also scanned then the analysis is incomplete (although still much better than nothing).
Remember that all errors do not have the same severity or impact the user experience in the same way.
That could seems pretty low considering how many people have had their hands in it "cleaning it up".
I would be proud to be a part of that team. Let me just say GOOD JOB!
I thought I would put my $.01 cents into the pool here - having recently been through something like this.
Background: I am the author of some fairly unique software tools that allow you to communicate with industrial Programmable Logic Controllers. I consider the tools I write to be libraries with some example code showing how to use the library. It's all fairly simple stuff but one of my packages does a crapload of mallocs as it reads objects from the controller - basically it mallocs a data struct for every object, and then it also mallocs the data store for each object based on the data type (byte size) and how many items there are (3 dimensional array). In other words, a huge number of mallocs with no associated free statements.
So one day I get an email from a guy who was interested in using my software but wanted to know when I was going to remove all the memory leaks from my code. He was kind enough to include a valgrind report that showed a huge number of memory allocations that were never freed. It took me forever to explain to the guy that while I could "eliminate those memory leaks", it would also destroy the value of the library as it would in effect delete all the data read out of the controller.
Moral of the story: bug reports (including things like these code checkers and memory analysis programs like valgrind) are nice, but they need to be properly applied to be useful. Otherwise, these reports can be a significant distraction.
Ron Gage - Westland, MI
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.
Yup, they will indeed be "spinning [it] wicked". But boy, wouldn't it be fun to see what would happen if the source for IE were opened up and a team of bug-finders who really liked their job spent a while ripping it apart?
IANAP but I think that 71 vulnerabilities in a FULL FEATURED web browser product is absolutely amazing. Just imagine if there was a chance to audit the source for IE? How many vulnerabilities do you think there would be, considering there are so many found without even LOOKING at the actual codebase?
It is pitch black. You are likely to be eaten by a grue.
It's called constructive criticism. And it's all about trying to make a great product even better.
This sig will self destruct in 5 seconds.
Of course this kind of analysis is welcomed. Open Source claims to write better and more secure code than closed operations as a result of community involvement and look-at-the-source-for-yourself accountability over the quality of the product. Therefore, this analysis directly supports the mission of open source. What I'd like to see is Microsoft submitting IE to the same public scruitny and maybe the senders of the 10 emails I received about this /. would shut the hell up.
One day the toilets of the world will rise up... And I'm going to nuke them.
...I can say that I am glad it is being run on something like Firefox.
I just wish there was something similar I could run on my own code (or that others could run on their code), anyone aware of something similar?
Getting hysterical about not checking allocation results is seriously warped. In this case the end result of not checking allocation results is, at worst, that you then try to access a null location, causing your app to GPF. Whoop dee doo.
You do realize, don't you, that Firefox consumes that much because so much is available, right? There seems to be a general confusion out there about adaptive software that makes use of riches of memory.
Simply checking if the results are null is nowhere near a complete solution -- in complex code with many allocations, you then have to "unwind" - if such an action is possible at all - which can be enormously complex.
How do you think GC'd languages deal with an out-of-memory condition? Why they throw an exception in most cases, which in most languages walks right up the stack until the entire application fails (because, as you know, if you can't actually do anything with the exception, you aren't supposed to catch it). In other words, the end result is exactly the same as accessing a null reference.
When I posted the prior comment, I just KNEW that it would draw the ire of the armchair purist, so I came so close to checking off the anonymous box.
such as this should be considered good, as I'm sure the Firefox programmer community is generally doing. This is another ladder on the road to reaching critical mass of a user community. For years, I hated it when someone criticized my writing, but it finally dawned on me that most criticism is constructive and will be beneficial if it doesn't fall on deaf ears...
Firefox was never meant to be created in a vacuum, thus it should be taken as a compliment that this analysis was done.
I have this image in my head of an IE developer reading this story and thinking "Gee Slashdot, I guess writing a browser is pretty fucking hard, isn't it?"
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
"What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?"
No we prefer to be ignorant of the problems in software we write, we prefer to assume everything is perfect.
OF COURSE people prefer indepth analysis. I'm sure someone was like "damm it" when they got the report because they thought their code was flawproof but with the whole world as a consumer, people want to know what they can fix and make better, especially firefox who's core idea is create a browser that doesn't have problems like this.
Firefox is trying to build a better browser, the only way that can happen is if they get great and specific feedback ("the browser's too slow" doesn't help. "The browser's too slow when I go to this site" does.) Why would anyone not one an indepth analysis of a product you're currently working on? (the only time that sucks is if youre finishing it up for the final version and you will never work on it again and someone tells you about a year's worth of work left)
The more they find, the more they fix, the more secure Firefox becomes. That's the beauty of open source for you, folks. For IE you wouldn't even know about half the bugs and vulnerabilities (which doesn't mean hackers wouldn't know about them, though).
Touched by His noodly appendage.
They are no claiming that they have found security vulnerabilities, the say they have found potential security vulnerabilities. It is even possible that none of them are actually security vulnerabilities.
1.5.0.6. The analysis resulted in 611 defects and 71
You do realize that 611 + 71 is 682. And that 1506 + 682 = 2188. And that Feburary 1st, 1988 is in the year 1988, and that Kevin Karpenske who gave Firefox his domain has been (scroll down to see the post).
An *exposition* on *firefox*, well duh!
Have you read my journal today?
I am looking at Bugzilla right now and there are some 351,680 bugs in there. Everyone panic.
members are seeing something, your seeing an ad
..it might mean that in 682 possible places in the code, added/better documentation might be a good idea.
(he said with karma to burn)
OSX bugs -> tar, feather, blonde^H^H^H^H^H^H mac user jokes
MS bugs -> tar, feather, detailed scatalogical analysis of the gates family tree, ballmer monkey boy video links
OSS bugs -> mature & measured discussion, navel gazing, produndities, kudos all around
ah.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
Does the open source community that surrounds Firefox welcome this kind of analysis? I would have to say that's a RESOUNDING YES! As long as the analysis is truthful and reflects real problems that will improve the quality of Firefox I see no reason they wouldn't. Even pointing at minor issues will only help aid Firefox's improvement since it would give the developers a chance to see what people might really care about. And you can bet that if similar analysis was done of Internet Explorer that we'd find the same if not more defects and vulnerabilities. So this is NOT about Firefox vs. IE before anyone goes down that road.
-"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
Of course they welcome this. Just look at the results page for the Coverty scans and see how many defects have been fixed in major open source projects.
http://scan.coverity.com/
Rapid development happens all the time.... it puts QA in a crunch along with development. How about someone do a study on the other browsers, im sure the stats are the similar or higher. Of course more time helps, no one doubts that. At least this isnt EA Games with their retail releases are full of holes... this application is free you can choose not to use it.
In the end, it is no different than closed-source to those that can't code.
It is different.
If the developers aren't fixing bugs that you want fixed and you can't fix them yourself, you can get someone else to fix them for you. For example, you could pay someone to fix the bugs.
With closed source code, you don't have that option.
I have to mention that the tool will report a number of warnings or so called errors that are noise in the output, as most tools have this problem.
Lets not forget, the company that is analyzing the code is a company who sells a product to do just that. It could be seen as a marketing ploy as well since the code is open source, they can do that.
This is not to say that there are not errors, but no tool finds all errors without finding non errors.
The answer is yes but only if "Some folks at Klocwork" have no ties to Microsoft. Duh.
Heard any good sigs lately?
Being an 18-year developer I realize that I will probably get pummeled for saying this, but has anyone on the Firefox team that may be reading this looked at AppSight for root-cause analysis with respect to problem resolution?
Memory allocations will almost never fail -- not even when the machine is actually out of memory (VM). Most modern operating systems use overcommit since many programs tend to allocate far more memory than they actually ever use; untouched pages need not have any backing. I should also note that Linux does allow you to turn this behavior off, but I'm not sure about other operating systems.
Anyway, in the unlikely event that a memory allocation should fail, I believe the behavior of C++ is to return null if exception support is turned off, and throw otherwise.
HAND.
Who tagged Fud? 611 defects and 71 potential vulnerabilities sounds as less than what I was expecting of firefox, and this will help fixing them, so it is a very good thing.
Copyright infringement is "piracy" in the same way DRM is "consumer rape"
This means that shortly, there will be 611 more bugfixes and 71 more potential security fixes!
I bet they're more busy trying to come up with a killer feature for it so marketting can hype it up and it won't matter how stable the competition is. Redmond learned a long time ago that they don't ever need to have a good product - just the most desirable image.
(Note that the main bug report linked is always marked invalid. That's not because anything has been done about the instability of Firefox; it's because people on the Firefox team don't want to, or don't know how to, fix the very, very serious bugs. Note also the links to magazine articles about Firefox instability, and the many links to user reports of problems.)
I'm posting this comment from Firefox version 1.5.0.6. It is using 22 percent of the CPU, even though all pages have been loaded, and there is no active content. That's 22% on the way to 70% or more, which will soon make it necessary to close all windows and tabs of Firefox and reboot Windows XP. (Firefox corrupts Windows XP SP2 with all patches applied, so that it is necessary to restart the OS. In Linux, it is necessary only to kill Firefox to get full control again.)
The CPU hogging bug in Firefox runs the fan in a laptop computer continuously, meaning that expensive hardware maintenance will be required more often for heavy Firefox users.
Firefox has extensions, but they often make Firefox unstable. The Firefox team thinks that it is entirely acceptable to market Firefox extensions, but when the extensions cause Firefox to be unstable, to excuse the instability by saying that it is caused by an extension.
The 1.5.0.4 version of Firefox was quite stable, if the Flashblock extension was installed. The 1.5.0.6 version is unstable again.
The problem appears to be that Firefox does not allocate enough resources. If you open several Firefox windows and several tabs in each window, and leave them open for several days, or suspend or hibernate your computer a few times, you will find that Firefox has started to hog the CPU.
It is interesting to note that, when the latest version of Firefox is used with the latest version of Thunderbird, they both have trouble with the CPU hogging bug. The each corrupt the other. Weird, and seemingly a good clue to the flaw that causes CPU hogging.
Apparently everyone on the Firefox team wants to add features or work on easy bugs. Apparently also, browser programmers are not necessarily heavy browser users. People who often do research on the internet, and open several Firefox windows and many tabs, and leave them open for several days, are certain or almost certain to cause Firefox to become unstable, however.
Mozilla Foundation Top 14 Excuses for Not Fixing Bugs
Top 14 things Firefox and Mozilla developers say about those who report difficult bugs, collected during the last 4 years:
It's nice to see that the tests addressed the memory leaks and memory HOG status of Firefox.
I have noticed this especially when multimedia comes into play.
Having a browser for Windows that would tell the Internet to shut up when requested is key.
Hopefully they address this issue soon.
Internet Explorer analyze this!
FireFox Copy & Paste Bug: Fixed!!
What a fool believes, he sees, no wise man has the power to reason away.
Still, Firefox is more secure that IE6... I wonder how many holes are in that piece of swiss cheese software?
Mozilla Foundation Top 15 Excuses for Not Fixing Bugs
Top 15 things Firefox and Mozilla developers say about those who report difficult bugs, collected during the last 4 years:
And remarkably I said a simple statement of fact that said nothing about whether it was a good idea or not.
What an incredibly stupid thing to say.
I don't reckon 611 defects and 70 something vulnerabilities is that bad going.
This is the kind of number I'd expect on a small enterprise project with about 10 coders, lasting about 4 -6 months.
For something thats been tinkered with and expanded for near on three years (just as firefox, not even talking about the moz history) this aint bad at all.
Also you've got to take these "code analysis" things with a pinch of salt. Functions capable of returning null for example, only a small fraction of those would even be exposed to unvalidated input normally.
Sure these things should be sorted, but in my opinion it'll be a matter of weeks before all of these would be wiped out, with the caveat that when tfa says it gave the details to firefox, that it gave them more than a pretty management summary.
Wouldn't it be just typical for them to go, "Hey, we've found x defects in your code. Pay us and we'll tell you where they are."
Yes, as long as the analysis provides real, useful information.
I've seen cases before where security companies have discovered big piles of "vulnerabilities" in certain other high-profile open source products. The problem in those cases that made the "vulnerabilities" not entirely welcome "discoveries" was that really the security company had just run their automated code analysis product over the OSS codebase and dumped the results on the OSS community without looking over them first to weed out the sometimes large numbers of false positives. The security companies in those instances, presumably, were more interested in promoting their own security product ("look at all these vulnerabilities our product found!") than in truly enhancing the OSS product being examined.
Shit, that's depressing. Remember those halcyon days when we few, we happy few, we band of dorks touted our Linux desktops as rock-solid, with uptimes measured in months and sometimes years? When we mercilessly mocked Windows for its constant restarts, for reaching a level of baroque complexity so fearsome that all a user could do when something failed was to reboot the whole megillah?
So, nowadays, in the Linux desktop's most popular web browser, what's the first step one is to take when diagnosing any problem, in order for the developers to give you the time of day?
Restart the box.
Thanks, Firefox. Thanks a lot.
Laws do not persuade just because they threaten. --Seneca
Does anybody else think of Napoleon Dynamite when they read about defects? What if you're on a Gateway that's painted like a cow?
Oh. My. Pants. I saw that oo.org bug referred to in one of those posts that you link to.
Paraphrasing:
User: If you use the KDE save dialog, oo.org doesn't check before clobbering your files. Here's a simple three-line method to reproduce a bug that can cause users to lose data.
Developer: Works for me if I use the GTK or oo.org dialogs. *closes bug*
User: I said the *KDE* dialogs.
Developer: But oo.org uses its own dialogs. That's KDE's problem. *closes bug*
User: There's an option for using native dialogs! Right here! Also, no other KDE app has this problem. You're not using the filepicker correctly.
User 2: I can confirm this. Something's definitely up with the code interfacing with KDE's filepicker.
[five months pass]
Developer 2: Have you tried a newer version? Maybe it's fixed in the point release. Re-open if you're still having the problem. *closes bug*
I have to laugh, to keep from crying.
Laws do not persuade just because they threaten. --Seneca
Why wouldn't they want to know about potentially up to 71 vulnerabilities plus numerous other bits of code to cleanup?
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
Everytime I have to download another so called "patch" the version number remains the same(1.5.0.6)...something must be wrong!!!
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former. ~Albert Einstein
What's the motivation to fix it in an Open Source environment? Altruistic tendencies?
What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
First we have the obligatory borg-like, "the community" reference. But the question should be re-phrased to "How many of you are so emotionally immature and insecure that you'll throw a tantrum because there might be something not uber-positive said about Firefox, Linux, Gnome, KDE...?"
P.S. who is making these thought decisions for "the community"?
It is reviewed by an independent qualified reviewer who has access to the build and source materials versus not-reviewed.
I worked for a very proprietary OS development group that submitted its source to two independent review and verification organizations. We received a very detailed summary of their findings. We fixed all the issues and resubmitted and they accepted the results. It is how the resultant OS got the highest Common Criteria Security Rating ever given to an OS. And it was done with a proprietary development model. And later versions will get the review again.
I bring this up only to point out that Proprietary and Independent Review aren't necessarily mutually exclusive, all you have to do is find a way to get that quality independent review.
Sometimes the reviewer wants publicity. Sometimes $$$.
No matter, it is the review and the quality of the reviewers that matters.
BAE's STOP is the OS, BTW.
like when your SO tells you, "overall I think you're a really great guy, but here, I've compiled a list of your 611 significant defects and 71 major character flaws."
Do Firefox and the open source community welcome this kind of analysis?
Yes, you silly wanker.
"Former Microsoft security strategist Window Snyder is joining Mozilla to lead the company's effort to protect its range of desktop applications from malicious hacker attacks."
4 7254
http://it.slashdot.org/article.pl?sid=06/09/06/21
# ~: no sigs today
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.
What a fool believes, he sees, no wise man has the power to reason away.
Some may argue that because of these numbers Firefox is riddled with holes and is no more secure than IE or any other browser. Here's the thing, though. It is Firefox's open-source nature than made this analysis possible. An independent party (could have been you or me) did this analysis. Try doing that with IE. Microsoft isn't going to let you.
For a browser to remain competitive these days, it needs to have loads of features and be fast. Supporting features takes memory. Memory is often traded for time to make the browser fast. You can try a no-frills browser such as Dillo or Links if you need every spare kB of RAM and want to have a browser open.
What a fool believes, he sees, no wise man has the power to reason away.
I think this type of analysis is great.
But I'm worried that open source projects arn't analysing their code themselves. Perhaps its better to have this stuff out sourced to professionals? But surley theres professionals that wouldn't mind do this in their free time to benifit a project, like it seems someone has done here.
Also, cant this process be automated. Like testing. Why is some type of automatic analysis done on every Release candidate.
Would it be that hard to do? Why dont they do it already? Are they afraid of the work it will create?
Along with this type of analysis, programs should be put through regular profiling so as to be able to spot potential bottle necks.
Giving IE users a taste of their own medicine since 2005 - http://pods.-is-a-geek.net/
I'm running 2.0b2 right now. I wonder how many of them have already been fixed?
cp == b&
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Would the community welcome bug reports of bugs not found by an automated tool? Say for example I found 50 bugs by hand and submitted the report to the team.
Firefox is a big, old, hairy C++ program, and for a big, old, hairy C++ program, that's not so bad.
While Firefox is important right now, the open source community really needs to start working on a successor in parallel. And, no, that doesn't mean another big, hairy C++ program.
That FF is buggy is no big revelation. The fact that the source is open to peer review (an OSS advantage) and scrutiny means that there is hope. However, having tried Firefox 2.0b I've noticed it still suffers from chronic memory leaks -- which even seem to permeate into the X server. With a desktop uptime that's measured in months, although KDE does save session state, running such resource corrupting desktop apps isn't an option. I certainly cannot recommend FF to anyone with a PC with less than 1GB RAM, Windows or otherwise. Why consider FF when there better alternatives, such as Opera (closed) and Konqueror (open).
Given the million or so /. accounts the number of Firefox developers can't possibly be more than an insignificant fraction, but we are nonetheless here.
Way more than you.
What are we talking about again? Oh, right, a fucking web browser. Get some context you weirdo. Hyperbole appears to be your strong suit, however.
I'm sorry, did we start talking about mainframe programming? Oh, no, we didn't, nor are we talking about a banking application, or a database.
Down here in the real world -- you might want to visit some time -- the operating system raises warnings when memory gets low, and will start slogging slower and slower. Here's the funny thing: When memory is actually completely exhausted the system is basically hosed. I know I know -- it's us unprofessional people that are to blame. Or maybe...just maybe...operations actually desperately required that memory, causing a cascading fault that is unrecoverable.
Maybe you should meet up with the real world some day.
And I hope that pulsing vein throbbing away on your forehead, and your unjustified sense of righteousness, doesn't give you an early stroke. Maybe next time you're talking about a, ermm, fucking web browser you could keep just the smallest amount of perspective.
OMG! Firefox crashes along with the rest of the system, taking down the heart pump!
...And reading my name FROM THE EMAIL LISTED ABOVE is pure super techno fu. You must be some sort of elite hacker!
"because they can't make as many assumptions as a programmer who knows what's going on..." That's true. Of course, the next developer/maintainer who works on that code, or needs it to interface with it, or (heaven forbid!) re-uses it in another project won't know about all your assumptions, either. Whether you're engineering hardware or software, there's such as thing as trying to be too clever. It may seem easy today, but someday somebody will curse you while trying to find what has gone wrong. Think about how you feel when you find that long-gone developers not only made assumptions, but didn't describe exactly what they were, why they made them, and what's necessary for them to be valid. // and /* are your best allies when the new wears off the project!
But having done well over 25k installs of winxp through imaging and hand installs and scripting, and putting FF on about half, it's usually the windows install that's buggy, not the FF install.
FF has it's issues, but on the three machines in my house, FF uses 0% cpu. In fact, i have a single ie page open to Thotbot, and it's taking up the most cpu, FF is 12th, with 31 tabs open.
--
This sig is brok908sdn/#2
"The fact that these problems were found and documented by a third party who had unfettered access to the source seems to support the idea that source availability actually does improve quality."
Quality is not improved by finding problems, but by solving them.
I'm not sure if you're trolling or you're just in a bad mood, but I've noted that on all your three posts on this thread you mention the "Top 14 excuses". In the post I'm replying to, that list has no relation whatsoever with the rest of the post, it's just glued there like a sig. If I had mod points, I would have modded your post as "troll" (to any mod reading this, down a bit, not to -1).
Putting that list in all your posts is really counterproductive (if you want to make participate in the discussion I mean, if you're really trolling ignore what I've said).
As for your post, I agree with the others. Never seen the bug you're talking about (minimal CPU usage right now), but FF is a memory hog (hoards memory, but is tolerable). 1.5 also has a few annoying behaviours, like drag and drop crap (if anyone knows how to disable that, tell me) or middle click to paste (already disabled). In fact, I'm impressed that it turned out pretty stable, considering all I've been hearing about 1.5. I did keep 1.0 until a critical update forced me to upgrade, though.
(Using 1.5.0.6 on suse 10)
GPG 0x1B479C78
nt
Brain kills internet cells.
Well, the problem is that static ananlysis tools sometimes are having quite high level of false positives. Sometimes it might be about 80%, e.g. if a particular software uses it's own custom exception handling mechanism, etc. From what I saw in the report: most of those are 'possible dereferencing of NULL return' and such.
;-)
So, unless we can see a details of those 600+ bugs it's hard to tell if Firefox is buggy. I know for sure, that Coverity does analysis of Mozilla's software on a regular basis and the situation isn't that bad.
My point is that one shouldn't be in hurry of making conclusions
Take care, Cos
This article is just FUD but let's think it otherwise. If Firefox has 71 potential security vulnerabilities then how much do you think Internet Explorer has? I'd really love to see the real numbers for it. And I'd also like to know how these tests where performed to find a 'security holes'. I'd like to question all these tests since they are mostly bull. They can give glues where the software is or is not depending on who performs the tests. Microsoft will never open their source for somebody outsider to look at and analyze it. ;)
Ps. I personally think IE still has 666 holes in it's sources and at least one of these holes is a hole which won't never be fixed since it was made by goverment.
-Seeing the problem is ½ of solution-
"... I do wonder if there's something unique about your machine."
Numerous people have reported the CPU hogging bug, including some in this thread. I''ve tried several computers myself.
Interesting fact: If both Firefox and Thunderbird are running, Firefox sometimes causes Thunderbird to have the CPU bug. That fact seems to make it easy to find the bug. However no developer has ever read the bug reports, apparently.
The Firefox CPU hogging bug is also a very interesting social problem.
You didn't read the bug report, and there is plenty of evidence that none of the developers did, either.
The Firefox CPU hogging bug occurs only when several windows and several tabs are open for a long time, days sometimes. If Thunderbird is running, the problem is worse. If the user hibernates or suspends the computer, the problem is much worse.
Also, maybe there should be a list of excuses for the excuses.
And you reminded me of other excuses I had not yet documented.
The fact is, other browsers such as Opera are stable. No number of excuses will make Firefox stable; the bugs must be fixed. The media (see the link below) are starting to report Firefox instability; it makes sense to fix the bugs before Firefox gets a bad reputation.
Interesting social science fact: Considering the responses, it is apparent that no one has read the bug reports thoroughly in the 4 years that the bug has been reported. It's easy to know early that the CPU hogging bug will be difficult to find, and apparently no one has read further.
Since no one commenting on this Slashdot story has read the bug reports, apparently, it is useful to repeat here that there is one fact that is important. The CPU hogging bug occurs only when several Firefox windows, each with several tabs, have been open for hours or days. Suspending or hibernating the computer (in Windows XP) make the problem happen sooner.
Interesting computer fact: The CPU hogging bug is communicable! Sometimes Firefox causes Thunderbird to hog the CPU! My guess is that fact makes it considerably easier to find the bug, or at least eliminate almost all of the code.
Another fact: Many people have guessed, based on the behavior, that the CPU hogging bug is caused by insufficient allocation of resources inside Firefox.
Mozilla Foundation Top 20 Excuses for Not Fixing Firefox Bugs
Here are the top 20 things Firefox and Mozilla developers say to those who report difficult bugs, collected over the last 4 years. See also the extensive information provided in this Slashdot comment, Firefox is the most unstable program in common use, and the links in the comment.
One thing you may not realize is that open bug tracking systems are just that -- open. Most of the people triaging bugs in Mozilla are not developers. With Mozilla's bug tracking system, all you need to do is attach two test cases to bug reports, and then you can get editbug permissions. Anyone with editbug permissions can close bugs. Just because you reported a bug and you had a discussion with someone that closed it, doesn't necessarily mean you had any contact at all with a developer, either a full-time Mozilla developer or even a volunteer developer. It could be a sixteen-year-old who has done a bit of QA work. If you see someone abusing Bugzilla privileges, please contact Gerv Markham about the problem.
What a fool believes, he sees, no wise man has the power to reason away.
Let's assume what you say is true. Firefox is horribly unstable. However, many people never see this instability. They have no idea what you're referring to. So saying "fix the instability problems" means nothing to us. You have to explain in detail what stability problems you're seeing. That's the point at which you get stuck. Yelling that problems should be solved isn't helping. Information that can be used to figure out what problems you're referring to is helpful.
You're the person with the information about the problem. You must convey that information to a person that is able to solve the problem. You might want to discuss the bug in the Firefox Bugs forum at MozillaZine so you can work together with other people who are unlucky enough to see the same problem. When you've gathered enough information so that you can state what the problem is clearly enough so others can see the problem, it can be fixed. Until then, it cannot. All the ranting in the world won't change that.
What a fool believes, he sees, no wise man has the power to reason away.
You've made a lot of great points that can't really be debated.
While it doesn't undermine or refute your points in the slightest, I think the critical point here is the sort of application under debate: Of course for an embedded controlling system, a system kernel, or anything else of criticality, such oversights would be heinous. For a web browser, however, the worst outcome is really just a nuisance.
Well you are far more patient than I am. Once it started to thrash the swap file I would start closing programs.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
As a person who uses firefox regularly, I don't find it unstable. Sure, the latest release is a bit unstable, and had crashes like 3-4 times on me, but I find it completely usable. Frankly, it is difficult to have software that never crashes. In fact, in this fast pace of software development world, it is already acceptable by most that general software do have bugs and will crash.
So what does the Firefox list tell us?
This could be fixed by using a memory allocation function that throws an exception on out-of-memory, rather than relying on the programmer to remember to check every call. If the programmer forgets to use a try/catch block to check for exceptions, the worst that happens is that the exception propagates upwards to a higher-level 'catch-all' routine.
Again, this shows that returning a special value such as null is not always the best thing to do. If it's likely that programmers will forget to check it (perhaps because null is only returned in error conditions, and doesn't occur during ordinary use), then an exception would be a better way to signal an error. It also lets you give more information about exactly what the error was; you can have different exceptions carrying different messages for different things that went wrong, but null is just null.
Hmm, but later on in TFA I see a comment from a Mozilla developer:
So it looks like the Mozilla folk have already thought about these problems and done the Right Thing.
-- Ed Avis ed@membled.com
hey, yeah there's good ol' microcrap lowering that common denominator for ya ...