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?

434 comments

  1. Obvious. by keyne9 · · Score: 5, Insightful

    do Firefox and the open source community welcome this kind of analysis?

    Obviously, yes. Otherwise, open source would be closed-source.

    1. Re:Obvious. by legoburner · · Score: 5, Interesting

      Especially now that firefox is so popular. Firefox makes up 10% of users on the general Internet (as counter by thecounter.com), with IE at 85%. My own tech related site has 76.4% of users using firefox, with just 10.1% on IE, and my other more casual site has 23.1% firefox and 64% IE (the rest being safari, opera, konq, etc.)

    2. Re:Obvious. by LiquidCoooled · · Score: 1

      Actually, I welcome the analysis but I hope they gave the key developers some time to investigate their claims first.
      Like any possible exploit, the responsible thing to do is let them know.

      --
      liqbase :: faster than paper
    3. Re:Obvious. by Anonymous Coward · · Score: 4, Funny

      And thanks to the popularity, now adware is built for Firefox as well. Especially that Yahoo crap. Bleh!
      Like the kid that was goth before it was popular, it's time to change to a more obscure web browser.

    4. Re:Obvious. by Anonymous Coward · · Score: 0

      And thanks to the popularity, now adware is built for Firefox as well.

      It is? I hadn't noticed. Clearly it can't be a serious problem.

      The only "adware" I've seen for Firefox is AdBlock, which is the only reason I can bear to visit most websites today.

    5. Re:Obvious. by ClamIAm · · Score: 3, Insightful

      Well, there's certainly some developers who get pretty bitchy when you file bugs or point out errors they've made. Does that make their project(s) closed-source/proprietary? No.

      But the bigger point here is basically this: Slashdot editors appending a leading/flamebait question onto a story generates more responses, and more ad impressions, and hey look I fell for it too.

    6. Re:Obvious. by AceCaseOR · · Score: 1

      Agreed. The real question here is why does a /. Editor even need to ask that question?

      --
      Zagreus sits inside your head, Zagreus lives among the dead, Zagreus sees you in your bed and eats you in your sleep.
    7. Re:Obvious. by legoburner · · Score: 4, Funny
      Like the kid that was goth before it was popular, it's time to change to a more obscure web browser.

      MSIE 3.0 here I come!
    8. Re:Obvious. by ztirffritz · · Score: 2, Insightful

      I know that the parent's comment sounds obvious, but to some people it isn't. This is EXACTLY why open source is a better development model. This will lead to a stronger product in a shorter time frame. Yes it creates some more work, but this type of work is never complete.

      --
      Why doesn't anything interesting happen when I have mod points?
    9. Re:Obvious. by Anonymous Coward · · Score: 0

      The real question here is why does a /. Editor even need to ask that question?

      http://en.wikipedia.org/wiki/Rhetorical_question

    10. Re:Obvious. by WiFiBro · · Score: 1

      if you would actually check the report you wouldn;t have posted this.

    11. Re:Obvious. by Danga · · Score: 4, Informative

      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.
    12. Re:Obvious. by Pollardito · · Score: 1

      seriously, they really released 3.0!?!

      being the first to hear about things like this makes wading through all the dupe stories worth it

    13. Re:Obvious. by Irish_Samurai · · Score: 2, Insightful

      when will web designers stop checking the damn user agent

      A) When they get a firm grasp of the CSS box model and its quirks. This is a developer by developer evolution.

      or

      B) When the CSS support and compliance across browsers begins to share a larger commonality. Large enough so that browser quirks are moot points.

      or

      C) PHB's who come up with the site specs quit taking the lazy way out and telling their developers/designers to "just make it work in IE" so they can meet their deadline.

    14. Re:Obvious. by Cruise_WD · · Score: 1

      "Don't do in public what you don't want to be public."

      And that includes coding, surely? If you didn't want people looking at your code, you wouldn't put it up for download on your website.

      You'd have to have one hell of an ego problem and a very slim grasp on reality to tell people to "look at my wonderful code" then bitch when they point out its mistakes... ...oh, wait...this is the web, ain't it? My bad...

      --
      [ cruise / casual-tempest.net / xenogamous.com / transference.org / quantam sufficit ]
    15. Re:Obvious. by stunt_penguin · · Score: 1

      I think the way that the news is presented does make a difference, however; if it's a proper bug/defect/vulnerability report submitted to them and talked about on the 'net, then well that's great; but if it's the kind of thing that just gets sent straight to reuters with no context 'ZOMG 61 security holes in teh Fox!' then then it's bad press for the browser. From the article it seems this research/testing has been the former, so it's a good thing.

      --
      When the posters fear their moderators, there is tyranny; when the moderators fears the posters, there is liberty.
    16. Re:Obvious. by Reziac · · Score: 1

      All software has bugs. How you react to evidence of said bugs says a lot about your integrity as a programmer.

      Someone who really wants their software to be a great product is going to welcome the help.

      Someone whose ego is tied up in how "perfect" their code is, is likely to get all pissy about it.

      So... if they DON'T welcome this sort of analysis, it would be conclusive evidence that they're more interested in preserving their egos than in improving Firefox.

      --
      ~REZ~ #43301. Who'd fake being me anyway?
    17. Re:Obvious. by Anonymous Coward · · Score: 0

      Also, TheCounter is definitely undercounting Firefox. Their detection system uses 3rd party javascript, and there are several popular extensions which block such things.

    18. Re:Obvious. by Marillion · · Score: 1

      Former Police front-man, Sting, once said something along the lines of, "Hearing someone say they don't like your music is like hearing someone your girlfriend is ugly." Pride in ones work can be a great thing. I think developers who code from the Artist mindset, as opposed to the Accountant mindset, are especially vulnerable to criticism of their code.

      --
      This is a boring sig
    19. Re:Obvious. by IAmTheDave · · Score: 5, Funny

      Now, can we get them to run the tests on the Diebold voting machines?

      --
      Excuse my speling.
      Making The Bar Project
    20. Re:Obvious. by LiquidCoooled · · Score: 1

      I had read the article (especially this bit):
      The Firefox team has been given the analysis results, and they will determine if or how they will deal with the issues.

      What I was trying to clarify was whether the team had been mailed earlier and given a reasonable timeframe to examine the vulns.
      But you are right, further down he says he has not publically released the identified locations of such vulns so it isn't as important.

      --
      liqbase :: faster than paper
    21. Re:Obvious. by Anonymous Coward · · Score: 0

      Out of 15M hits or so this past week:

      MSIE 56%
      Moz 26.4%
      Saf 7.3%
      Opera 2.7%

    22. Re:Obvious. by compro01 · · Score: 1

      I've also come across a number of sites which are aggressively IE sites. they do both a user agent check and then they also ask the number of plugins, which catches the user agent switcher plugin.

      it's severely annoying, though, fortunecity, IE tab waltzes through it.

      --
      upon the advice of my lawyer, i have no sig at this time
    23. Re:Obvious. by bunratty · · Score: 1

      If someone makes a general overall criticism like "Firefox is the most unstable program in common use" I can imagine developers being offended or defensive. On the other hand, developers welcome clearly written bug reports that identify one specific problem like "Firefox crashes when visiting site xyz.com", because then they can address that issue by reproducing the problem. A detailed list of 611 defects and well-written bug reports are always welcomed!

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    24. Re:Obvious. by Boone^ · · Score: 1

      Agreed. Open Source is meant for viewing by many eyes (and AIs) to make it perfect. It takes an internet to raise a browser.

    25. Re:Obvious. by Futurepower(R) · · Score: 1

      "Well, there's certainly some developers who get pretty bitchy when you file bugs or point out errors they've made."

      Not just bitchy; they make excuses. See Mozilla Foundation Top 14 Excuses for Not Fixing Bugs at the bottom of the linked page.

    26. Re:Obvious. by CAIMLAS · · Score: 1

      what kind of sites are you going to? i've not seen a site like that in years.

      --
      ~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
    27. Re:Obvious. by Mister+Whirly · · Score: 0, Offtopic

      "Former Police front-man, Sting, once said something along the lines of, "Hearing someone say they don't like your music is like hearing someone your girlfriend is ugly.""

      Which would carry a lot more weight if his girlfriend wasn't ugly. (and if all his post-Police work didn't suck)

      --
      "But this one goes to 11!"
    28. Re:Obvious. by SebNukem · · Score: 1

      I personally have a 0% IE hit count now that I incorporated this little gem in my web pages:

              for (x in document.write) { document.write(x); }

    29. Re:Obvious. by martalli · · Score: 1

      Why not NCSA Mosaic 1.0. I'll bet that doesn't even support pop-up windows. Barring that, I could just go back to gopher...

    30. Re:Obvious. by Anarke_Incarnate · · Score: 1

      Glad to see another person saw that wonderful movie. I'm taking it back!!

    31. Re:Obvious. by rainman_bc · · Score: 1

      . 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.

      So instead of MSIE holding 85%, we'll have it holding 85.5%...

      Opera is not very relevant, although you might like it ( Personally I think it's an okay browser though I reported a bug in Opera and they turned to me and claimed it's a site issue and not a browser issue... Hardly a response from an underdog browser. Had to revert back to FF because of it.)

      --
      09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
    32. Re:Obvious. by Analogy+Man · · Score: 1
      I have this problem with corporate internal sites...both my own company and others where I consult for sufficient duration to use their systems. Many large corporate installs have "Common Office Environment" builds...users do not have the ability to install software (although non-registry punching installs can get around this) and the only IE is installed.

      Since only IE is installed...internal sitedevelopment teamss have the requirement "work with IE", rather than to follow standards x,y, and z.

      --
      When the people fear their government, there is tyranny; when the government fears the people, there is liberty.
    33. Re:Obvious. by Danga · · Score: 1

      You porchmonkey you haha

      --
      Hey, there is only one Return and it's not of the King, it's of the Jedi.
    34. Re:Obvious. by SirusTV · · Score: 1

      Dude! Can I plug my own site too? its http://www.sirus20x6.com/ make sure to click lots of adds and stuff too. Why not submit me to get on the first page too! that would be awesome to get /.ed

    35. Re:Obvious. by acherusia · · Score: 1

      And then there's those people who make their useragent identical to Google's in hopes that they can get into paid content, and forget to take it off. *whistles innocently* It's a little more difficult in Firefox than Opera, since you have to go to about:config, and add the field general.useragent.override. Which you can then define as whatever you want.

    36. Re:Obvious. by Barsteward · · Score: 1

      "they turned to me and claimed it's a site issue and not a browser issue." So whats your problem - they say its not a Browser issue, its a site issue. Could you prove it was not a site problem? Do want them to rewrite Opera for a site that is not standards compliant? Just because FF works doesn't mean the site is W3C compliant.

      --
      "The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
    37. Re:Obvious. by AnyoneEB · · Score: 1

      Or just install the user agent switcher extension, which will provide a GUI for the same thing.

      --
      Centralization breaks the internet.
    38. Re:Obvious. by aztracker1 · · Score: 1

      A: Not as long as developers^udesigners rely heavily on WYSIWYG editors.

      B: Microsoft is dead... long live Microsoft.

      C: Cool, hell has ice skating...

      --
      Michael J. Ryan - tracker1.info
    39. Re:Obvious. by Ponga · · Score: 1

      Agreed. But you know what these metrics WILL tell you? The LEAST POSSIBLE percentage of users with non-IE browsers. Although these browsers can spoof the user-agent, IE cannot. Thus, when someone says "12% of browsers are Opera" that means AT LEAST 12% are Opera. And then tack on whoever is using Opera, but spoofing the user-agent (not possible to track)... But you are right, not a solid metric by any stretch.

    40. Re:Obvious. by Anonymous Coward · · Score: 0

      Sadly I remember using MSIE3 before I realized you could download an upgrade. By that time, IE5 was out. And that was a looooooooooong download.

    41. Re:Obvious. by TENTH+SHOW+JAM · · Score: 1

      And as far as intranets go, great. Company X can use whatever they like as part of their standard build. If they are developing for an intranet, then it makes sense to use the company approved browser.

      If however they are developing for the "Intarweb" (as my boss so affectionaltely calls it) then any sane developer is going to ask for as may browsers as they can cram on a test environment. What's that? No test environment? You mean you are testing on your production system? Please note the rapidly evaporating sympathy.

      Since quite a few browsers are free or come with the OS, then there should be no excuse to their install as it costs the company nothing but time, and results in good feelings from customers who get the information that they want without jumping through browser war hoops. Can a developer develop for all the quirks? No. They should be programming for a standards based page, and add checks for the top 3 browsers (based on their own stats, not those of some tech journal) to remove error.

      Does this mean that "MyFavoriteBrowser" is left out in the cold? Possibly, if it's render engine is not up to par. This is the way of things.

      --
      A sig is placed here
      To display how futile
      English Haiku is
    42. Re:Obvious. by Anonymous Coward · · Score: 0

      There have been tests, they've found problems, but the local Secretary of State is corrupt, and the mainstream media has a blackout on the whole topic. Anyway, It isn't going to matter if Congress can just swear in a candidate before the votes were even counted or certified. And now citizens no longer have the right to supervise elections.

      My Advice is to

      1.) Freeway Blogging
      2.) Hometown Broadcast Media Swarm/Protest
      3.) FCC Station licence files/Public File (when they renew for their frequency, these files get reviewed.)
      4.) Save, and Support Public Access (From the Telcos)
      5.) Save The Internet (net nutrality)

    43. Re:Obvious. by rainman_bc · · Score: 1

      Do want them to rewrite Opera for a site that is not standards compliant?

      Had nothing to do with standards. Opera claimed a security hole where MSIE, FF, KTML and Safari did not. They are the underdog. If they want market share, they should be more compliant, not less.

      It had to do with a frame redirecting the top to another server. All other browsers allow it, Opera disallows it.

      --
      09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
    44. Re:Obvious. by Propaganda13 · · Score: 1

      I was in a giving mood so I clicked. I saw no ads and IE 6.0.2900.2180 said errors on the page. I've got work to do otherwise I'd investigate further.

    45. Re:Obvious. by MadMidnightBomber · · Score: 1
      Like the kid that was goth before it was popular, it's time to change to a more obscure web browser.
      MSIE 3.0 here I come!

      Ahem. He said a web browser.

      Jamie, who dimly remembers hacking web pages to work with MSIE3, Netscape, Mosaic and lynx all at the same time.

      --
      "It doesn't cost enough, and it makes too much sense."
    46. Re:Obvious. by aichpvee · · Score: 1

      I've seen that happen with multiple banking sites. I saw some site a few weeks ago that wouldn't let me view it using Firefox because it "required" ie or netscape, wtf?!?!

      --
      The Farewell Tour II
    47. Re:Obvious. by eosp · · Score: 3, Informative

      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.

    48. Re:Obvious. by Anonymous Coward · · Score: 0

      Puh-lease, AOL 3.0 running on Windows 3.1, dats how I rolls.

      (It took me forever to find a copy of AOL 3.0, which I think is that last version of AOL to support Windows 3.1)

    49. Re:Obvious. by page0 · · Score: 1
      the open source community welcome this kind of analysis?

      The biggest hole in the OSS concept was "tons of people will be reading our code and thus be able to fix our bugs and develop enhancements". In a couple of decades of engineering, programming, and project management, I don't recall anyone saying "hey, I'll spend my non-existent free time doing a thorough code review before tweaking this code to do what I want".

      Hopefully I have been proven wrong...

    50. Re:Obvious. by ncc74656 · · Score: 1
      I've also come across a number of sites which are aggressively IE sites. they do both a user agent check and then they also ask the number of plugins, which catches the user agent switcher plugin.

      Two can play that game. (Go here with IE to see it in action.)

      --
      20 January 2017: the End of an Error.
    51. Re:Obvious. by billeger · · Score: 1

      ...and welcome! As a FireFox user it is great to see the effort to to find problems and see them given to the group that can fix them!

      --
      Those who trade freedom for security will soon have neither.
    52. Re:Obvious. by richlv · · Score: 1

      well... ibm hardware configurator (in their website) does not work with opera (on linux, if that matters).
      so even companies that embrace alternatives do not always get it right.

      --
      Rich
    53. Re:Obvious. by Anonymous Coward · · Score: 0

      That's why I keep a copy of old browsers on cd. aol 3, 4, 5, netscape 2, 3, 4, and ie 2, 3, 4.

    54. Re:Obvious. by compro01 · · Score: 1

      i'm not sure if you read my post. this trick makes a user agent switch ineffective. it basically asks a trick question.

      site: what browser are you?
      browser: i'm IE 6.0
      site: how many plugins do you have?
      browser: 4
      site: WRONG ANSWER! IE doesn't use plugins! *denies*

      --
      upon the advice of my lawyer, i have no sig at this time
    55. Re:Obvious. by SirusTV · · Score: 1

      It's been up less then a week and I only have firefox at the moment. I got the hosting for free and threw some ads up to see what would happen. I made about 10 bucks in the last few days. Not too shabby for something I got for free. There is most likey an xhtml problem with the order I have tags or something, but I just checked it on my friends machine with IE 6.0.2900.2180.xpsp_sp2_rtm.040803-2158 and it worked (Who the hell would make a version number that long. why not 6.1?)

    56. Re:Obvious. by Apoklypse · · Score: 1

      so it's clearly a site issue where the site is attempting to redirect you to an OUTSIDE server in an INSECURE manner possibly leaving you the user open to exploits and attacks from NON_TRUSTED sites

  2. Memory leaks by Anonymous Coward · · Score: 5, Interesting

    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.

    1. Re:Memory leaks by Anonymous Coward · · Score: 0

      Doning this kinda of analysis is much easier with the source code i imagine.

      Actually, it's much easier without the source code, although the results are probably a lot less accurate.

    2. Re:Memory leaks by kripkenstein · · Score: 4, Insightful

      TFA mentions 80 possible memory leaks and 54 certain ones (as certain as you can trust their software, but that's something else). That doesn't sound like very much for a large project like Firefox. Still, Firefox does seem to use more memory than it should, at times. Perhaps these newly-identified defects are related to such behavior?

    3. Re:Memory leaks by random_culchie · · Score: 2, Interesting

      This and the God-damned copy and pasta bug!!! Firefox devs fix this one long term bug and I will sacrafice some cattle. I swear. Its driving me nuts..

    4. Re:Memory leaks by sharkey · · Score: 5, Funny

      God-damned copy and pasta bug!!!

      What, is it giving you spaghetti when you wanted ravioli?

      --

      --
      "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next.
    5. Re:Memory leaks by random_culchie · · Score: 2, Funny
      God-damned copy and pasta bug!!!
      What, is it giving you spaghetti when you wanted ravioli?
      Mamma Mia!
    6. Re:Memory leaks by Hoi+Polloi · · Score: 1

      I hate it too when my ravioli get screwed up.

      --
      It is by the juice of the coffee bean that thoughts acquire speed, the teeth acquire stains. The stains become a warning
    7. Re:Memory leaks by idhindsight · · Score: 0

      No, seriously. What copy-and-paste bug?

    8. Re:Memory leaks by morgan_greywolf · · Score: 4, Funny

      God-damned copy and pasta bug!!!

      What, is it giving you spaghetti when you wanted ravioli?


      It's what he gets for using a pirated version of Firefox! ;)
    9. Re:Memory leaks by cerberusss · · Score: 1

      Hi troll, I'm not going to bite but instead redirect you to a useful Firefox wiki.

      --
      8 of 13 people found this answer helpful. Did you?
    10. Re:Memory leaks by CCFreak2K · · Score: 2, Informative

      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."
    11. Re:Memory leaks by random_culchie · · Score: 1

      The one where you copy something in firefox and it doesn't go into the clipboard.

    12. Re:Memory leaks by Dan+Farina · · Score: 2, Interesting

      Except this isn't a memory leak, but is in fact intended behavior. A memory leak is a fairly specific and (and in this case) a non-applicable bit of terminology, unless there is more to that article and comments linked to that I'm not seeing. You could instead argue that the behavior is not a good one unless you point to a reference that shows that this memory usage is, in fact, caused by a leak.

      On one side of the fence are those who say ram is cheap and we shouldn't care, but when "big" becomes "too big" is a point that is of some subjective judgment. I for one never have swapping problems with my workload and have firefox open for days, so I'm not inclined to care.

    13. Re:Memory leaks by defMan · · Score: 1

      Do you have a bugzilla bug number for this? I'd like to have a look at the details. I've never had this problem (yet).

      But i'm using the linux version and the linux 'clipboard' works different from the windows clipboard so that could be the reason i haven't seen it.

    14. Re:Memory leaks by Z34107 · · Score: 1

      A cache of recently-visited pages is nice.



      Why they can't free up the memory the cache used AFTER THE BROWSER IS CLOSED is beyond me.

      --
      DATABASE WOW WOW
    15. Re:Memory leaks by Anonymous Coward · · Score: 0

      Oh, christ, this has been driving me fucking batshit CRAZY since 1.5. Also, sometimes keyboard focus goes nowhere. I have zero idea how to reliably reproduce this, so I haven't filed a bug, but I'm getting ready to switch away. It's horrible.

    16. Re:Memory leaks by Anonymous+Brave+Guy · · Score: 1

      I don't know if there's a specific bugzilla report for it. I certainly haven't been able to reproduce it in a useful way to file a bug report, but I see it very frequently, and it's become much worse somewhere along the 1.5.0.x point releases. I'm using the Win32 version, with various web development extensions and not much else in the way of add-ins, FWIW.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    17. Re:Memory leaks by Anonymous Coward · · Score: 0
    18. Re:Memory leaks by Anonymous Coward · · Score: 0

      So, after they fix all these, does that mean that we won't have people bitching about memory leaks any more? :)

      Or will they continue to do so because they don't realize that 650 of the 700 MB of memory Firefox is using is all that porn they have loaded in tabs?

    19. Re:Memory leaks by Alphager · · Score: 1
      Actually, it's much easier without the source code, although the results are probably a lot less accurate.
      Care to elaborate on that one? Can one make an analysis of the Produkt not using the Source Code? OSS: Yes. CSS: Yes. Can one make an analysis of the Produkt using the Source Code? OSS: Yes. CSS: NO.
    20. Re:Memory leaks by Anonymous Coward · · Score: 0

      God-damned copy and pasta bug!!!

      What, is it giving you spaghetti when you wanted ravioli?

      This is why you should never preview your messages before you submit them.

    21. Re:Memory leaks by Anc · · Score: 1
      This and the God-damned copy and pasta bug!!! Firefox devs fix this one long term bug and I will sacrafice some cattle. I swear. Its driving me nuts..
      Then help them out and find a reliable way to reproduce the problem. The reason why it hasn't been fixed for such a long time (which isn't entirely true as at least some variations of it were) is because nobody has been able to do the above. On some machines/installations it happens all the time, on others it doesn't. If you can figure out the exact circumstances under which this bug occurs, than the devs can trace the code path and you can be sure it will be fixed ASAP. It's that simple.
    22. Re:Memory leaks by The+MAZZTer · · Score: 1

      What OS are YOU using that it doesn't free memory allocated to a process after the process exits? Upgrade to something released this millennium, thanks. Windows NT based OSs and Linux are both acceptable.

    23. Re:Memory leaks by Xanthis · · Score: 1

      Well.. if it was written in spaghetti code it would.

    24. Re:Memory leaks by FictionPimp · · Score: 1

      It's not like he didn't tell you how to fix this "memory leak" yourself.

    25. Re:Memory leaks by Anonymous Coward · · Score: 0

      laffo he's a pasta pirate.

    26. Re:Memory leaks by john83 · · Score: 2, Funny
      It's what he gets for using a pirated version of Firefox! ;)
      Is that the new Fi-arr-fox I keep hearing about?
      --
      Strange women lying in ponds distributing swords is no basis for a system of government.
    27. Re:Memory leaks by Anonymous Coward · · Score: 0

      learn English

    28. Re:Memory leaks by supersnail · · Score: 2, Insightful

      Ah the joys of mechanical bug tracking!

      What there software has identified is either paths through the code
      where the software given the right set of variables could just possibly
      leak memory , and, paths which when taken will leak memory.

      This does not necceserily translate to memory leaks in real life.

      Commercial products such as "purify" have been doing this stuff for years.
      The main problem with using these tools (apart from the queasy feeling
      you get when it generates a 200 lines of warnings and errors for your
      50 lines of code) is identifing real leaks in the mass of potential
      leaks reported.

      Fixing them all is not really an option as they report things like:--
            Storage blocks you intend to use in other routines but you stored the
            the address somewhere else.
            Things you don't bother releasing because you are bailing out as
            quickly as possible.
            You have your free tucked inside a conditional as in:
                  if (lasttime == true) { freemem(stuff); }
            You you use memalloc as a way of allocating what is essentially
            static storage. e.g. You have "buffersize" set in a config file
            and allocate the memory during intialisation and never free it.

      If you try to get round this by coding extra freemems you just end
      up with lots of "possable memory free twice" error messages.

      C programers usally code a wrapper for malloc and freemem so they can
      track these problems themselves.

      --
      Old COBOL programmers never die. They just code in C.
    29. Re:Memory leaks by Ophion · · Score: 1
      It's what he gets for using a pirated version of Firefox! ;)

      Exactly. Why do people still question the benefits of Firefox Genuine Advantage?

    30. Re:Memory leaks by CAIMLAS · · Score: 1

      certainly!

      I wonder if they included "fails to free memory" as a leak or potential leak? I'm sick and tired of FF tabs getting closed and the memory they were using to remain resident. sorry, 300Mb should NOT be resident "just started the browser" use, no matter how many tabs I've got open via seesionsaver...

      --
      ~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
    31. Re:Memory leaks by bunratty · · Score: 1

      The breakdown is more like this:

      53% null pointer dereference (crashes)
      17% memory leaks (generally in error conditions)
      1% serious memory problems that could cause crashes
      8% uninitialized variables (could causes crashes or other erratic behavior)

      Given that there are hundreds of memory leak bug reports in Bugzilla, and the memory leaks found by this analysis occur generally only in error conditions and therefore are fairly rare, I don't think this report is going to have a huge impact on memory leaks. The good news is that I've been using Firefox 2 Beta 2, and it's leaking memory at such a slow rate that it would take weeks to eat up the memory on a computer that has just 256 MB of RAM.

      If you're seeing a severe memory leak in Firefox 2 Beta 2, make sure it's reported in Bugzilla, with enough detail that others can reproduce the problem. Remember that it's normal for a browser's memory use to climb over 100 MB on the first day of use. Memory leaks generally don't become apparent until after several days of use. If you see Firefox 2 leak more than that, see earlier in this paragraph.
      --
      What a fool believes, he sees, no wise man has the power to reason away.
    32. Re:Memory leaks by Khyber · · Score: 1

      All of my memory leaks in FF went away the second I banned Flash and Java from my machine altogether. Open up a few Myspace pages with Flash, then try another computer with FF without any plugins installed. Watch which computer's memory usage skyrockets.

      --
      Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
    33. Re:Memory leaks by Kelson · · Score: 1
      It's what he gets for using a pirated version of Firefox! ;)
      Is that the new Fi-arr-fox I keep hearing about?

      Nay, that would be the grand ship FyreFawkes, matey.

    34. Re:Memory leaks by Psykosys · · Score: 1

      Noting a problem is hardly trolling. If I leave my Firefox windows open overnight alongside a bunch of IE windows, and it's Firefox that's taking up all the memory by morning, I consider that to be a problem. Not one that prevents me from thinking it's the browser most worth using, but a major invonvenience nonetheless. And that Wiki guide, while helpful, does not present a solution to memory leaks besides ones triggered by extensions. The very nature of a leak means that it can't be handled through the solutions in the Wiki, which involve lowering the amount of memory Firefox is supposed to use. 0 That said, the latest builds have improved things dramatically and it looks like devs are really taking the issue seriously (thanks in part, no doubt, to the complaints of many "trolls").

    35. Re:Memory leaks by Peter+Mork · · Score: 1

      Do you use a Windows desktop manager? I can reliably recreate cut-and-paste bugs, inability to scroll using arrow keys, and many other bugs by opening a couple of tabs, switching to a different desktop, switching back and immediately changing tabs. I got so frustrated that I switched to Opera. I haven't opened Firefox in months, and I'm so much happier! (I documented all this in a bug report, but I don't believe anything has been done about this.)

    36. Re:Memory leaks by Peter+Mork · · Score: 1
      Remember that it's normal for a browser's memory use to climb over 100 MB on the first day of use.

      Egads! I consider anything over 50MB to be excessive. I currently have a half-dozen tabs open (many have been open since early this morning) and the memory usage is below 37MB.

    37. Re:Memory leaks by mrbcs · · Score: 1
      You know, as much as I hate AOL, I have been using Netscape 7.2 since it came out. I find this to be THE most stable Netscape I've ever used. I prefer the integration of email and browser. I've tried Firefox a few times, but it just causes me too much grief. I upgraded to win2k and since my mahcine is finally stable, it really burns my ass to have problems with a program anymore. I'll use this os and browser till I can't use it anymore.

      I've tried about 40 linux distros, and while I totally support their (open source)efforts morally, I'm too bloody old to put up with problems. I have yet to find one Linux Distro that does everything I want. It's getting closer, but not there yet. I do realize that Firefox works great on Linux.. I have not had that success in Windows.

      --
      I'm not anti-social, I'm anti-idiot.
    38. Re:Memory leaks by Anonymous Coward · · Score: 0

      Not meaning to bash one of the best (though a very slow one;) browsers out there, but I thought that even _one_ memleak is a very bad thing. Guess I'm oldschool or something.

    39. Re:Memory leaks by dreamlax · · Score: 1

      At least we can all agree that spaghetti code is bad.

    40. Re:Memory leaks by Anonymous+Brave+Guy · · Score: 1

      Nothing non-standard in the desktop manager department here, though I've long suspected something related to the tabbing issue you mentioned. In particular, if I've got more than one Firefox instance open (as in, two entries on my task bar) then I think something is up with switching between the instances, and sometimes closing one will allow previously broken scrolling in another to work. As I said, I'm afraid I haven't yet figured out exactly when things go wrong, though.

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
    41. Re:Memory leaks by Anonymous Coward · · Score: 0

      That doesn't seem to be the proper solution to the problem, however. Some pages have flash content I'd like to see, and the NOAA weather radar uses Java, so I'd much rather have them WORK with Firefox than not.

    42. Re:Memory leaks by Anonymous Coward · · Score: 0

      I had a site where i could make this occur on demand. Bugged it. Was fixed, they did another update, it came back, bugged it again, was fixed in another update, now its back, though only intermittantly. I hate those kinds of bugs.

    43. Re:Memory leaks by mrraven · · Score: 1

      Why does a browser need to eat a 100 megs, is that mostly cached images? If it isn't that insane. I remember when entire operating systems with guis came on half a dozen 1.4 meg floppy disks.

      --
      Tired of all the isms, don't exploit people as an employer, or a government, mmmmK?
    44. Re:Memory leaks by bunratty · · Score: 1

      My memory usage regularly goes over 200 MB, then back down to about 100 MB when I close all tabs. I tried Opera 9 when it first came out and its memory use went over 100 MB within a few hours. When memory use won't go below 200 MB without closing the browser, then you know you have a problem.

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    45. Re:Memory leaks by Anonymous Coward · · Score: 0

      This is delicious copy pasta. You must eat it.

    46. Re:Memory leaks by bunratty · · Score: 1

      Extensions are also a common source of memory leaks. Report leaks in plug-ins and extensions to the developers of that software.

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    47. Re:Memory leaks by bunratty · · Score: 1

      I have 1 GB of RAM, so the memory cache is 18 MB and the bfcache holds the last 8 pages I had open (pages take an average of 4 MB each). That adds up to 18 + 32 = 50 MB for cache out of 100 MB. The rest of the memory use is due to memory fragmentation, loaded plug-ins, XUL cache, etc.

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    48. Re:Memory leaks by mrraven · · Score: 1

      Is 100 megs what we should expect from a browser from now on? I have 2.5 gigs of ram on my dual G5 Mac and I need every spare K when doing photo manipulation work. If browsers are going to start taking 100 megs plus I'll have to keep mine closed when doing photo manipulations which sucks because I like to upload to flickr directly when I'm done.

      BTW my copy of Firefox is at 42 megs now with only one tab open. I thought Firefox was supposed to be the slim trim fast browser, where did it all go wrong?

      --
      Tired of all the isms, don't exploit people as an employer, or a government, mmmmK?
    49. Re:Memory leaks by Anonymous Coward · · Score: 0
      Care to elaborate on that one? Can one make an analysis of the Produkt not using the Source Code? OSS: Yes. CSS: Yes. Can one make an analysis of the Produkt using the Source Code? OSS: Yes. CSS: NO.


      And which analysis is easier? What the fuck do you want him to elaborate on, dumfuk?

      Fucking moron.

    50. Re:Memory leaks by Anonymous Coward · · Score: 0

      Methinks it was a joke, and one that soared way above your head.

    51. Re:Memory leaks by cerberusss · · Score: 1

      Okay, so you can reproduce this reliably? You can make Firefox eat ~700 MB? Is it as simple as a Windows 2K box with Firefox leaving running overnight?

      --
      8 of 13 people found this answer helpful. Did you?
    52. Re:Memory leaks by Cederic · · Score: 1


      54 certain memory leaks is exactly 54 too many. To you it maybe doesn't sound like very many for a large project like Firefox but to me it sounds like 54 too many. Why are there any at all? Aren't developers learning from 50 years of software engineering?

      At no point in computing history have memory leaks been acceptable on any size project.

      That doesn't mean they haven't been tolerated..

    53. Re:Memory leaks by Anonymous Coward · · Score: 0

      Well, guess what? Netscape 7.2 *is* Mozilla on the inside.

    54. Re:Memory leaks by julesh · · Score: 1

      Also, sometimes keyboard focus goes nowhere. I have zero idea how to reliably reproduce this, so I haven't filed a bug, but I'm getting ready to switch away.

      It's already filed and being ignored, as per usual approach. The problem is that the focus can be put into a tab other than the currently active one. This can happen if you switch tabs through the keyboard interface, or if a script running in a non-active tab calls someControl.focus().

    55. Re:Memory leaks by Psykosys · · Score: 1

      I don't have that much RAM to start with. But yes, on a Windows XP box with 512MB RAM, 10 or so Firefox Windows open, and standard extensions like AdBlock (but none on their leaky extensions list) enabled, Firefox's memory consumption will likely grow overnight to consume all or virtually all available memory. I haven't tried this with any of the latest builds, but if you go back 6 months, to the versions everyone was complaining about and you were presumably defending then, I can guarantee you that you will be able to reproduce it reliably. No such guarantee for the latest versions, which, as I said, seem to represent significant improvements.

    56. Re:Memory leaks by cerberusss · · Score: 1

      OK so it's not a problem anymore. Then I don't understand this complete thread to begin with...

      --
      8 of 13 people found this answer helpful. Did you?
  3. It's a critical review by 91degrees · · Score: 1

    And nobody actually likes hearing the negative parts of them, but the wise will consider them and work on resolving the problems.

  4. YES! by Total_Wimp · · Score: 5, Insightful
    What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?

    God I hope so. What on earth is the advantage of open source security if they don't get this kind of analysis?

    TW
    1. Re:YES! by mgblst · · Score: 1

      Well there is analysis, and then there is analysis. If this is good analysis, which actually provides some useful information that can be used to improve firefox, then good. If this is bad analysis, as it may well be, then what is the use, except for someone to advertise there program, and to make people think that firefox is no good.

  5. Why Not? by eldavojohn · · Score: 5, Insightful
    What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
    And why wouldn't they?

    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:
    By far, the majority of the defects reported were null pointer dereferences (446 defects). A large number of defects resulted from the code not checking for null after memory was allocated. In addition, there were many cases where the return value of functions designed to return null were not checked prior to dereferencing.
    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.
    1. Re:Why Not? by RAMMS+EIN · · Score: 4, Insightful

      ``As far as some of these other problems that are mild security issues, they might not need to fix them at all.''

      Rule #2 of security: there is no such thing as "mild security issues".

      (Rule #1 is that the only secure system is no system at all)

      --
      Please correct me if I got my facts wrong.
    2. Re:Why not? by BL08N0883N · · Score: 1

      I concur. The flaws are openly known and will be solved openly. And with increasing open source consideration and adoption and companies like McAfee not offering any Linux OS security solutions, we can move this in a positive direction.

      --
      Jeff for President
    3. Re:Why Not? by arth1 · · Score: 3, Interesting

      Why wouldn't they? Ego, unfortunately. Open source developers are just as human as commercial developers, and don't like anyone badmouthing their babies.
      Yes, I expect a fair number of these bugs to be fixed, but I also expect a fair number of them to be closed without action, if there's any way to pass the blame.
      "Package A leaks memory when used with package B? Package B needs to free the memory we allocate. Not our fault. *CLOSED*"
      "Package A has a buffer overflow vulnerability? Packages B and C must filter the strings they send us. Not our fault. *CLOSED*"
      "Package A has a buffer overflow vulnerability when used with Unicode? It's designed as a single-byte character routine. If you want a multi-byte one, write your own. Not our fault. *WONTFIX*"

      I hope and trust that most of the bugs will be fixed without politicking and passing the buck, but I fear there will be quite a bit of focusing on blame placement and credit taking instead of getting a thankless job done.

      Regards,
      --
      *Art

    4. Re:Why Not? by Anonymous Coward · · Score: 0

      Either way, this is the beauty of open source software, anyone can go in and do this.

      But where are the details of this analysis? With 611 defects and 71 security bugs, do you really think the developers can fix this in a timely manner? Do you really think they're going to fix them all? That's the beauty of open source, it works just like public works projects: put up a "Men at Work" sign in the summer and watch the years roll by.

    5. Re:Why Not? by Anonymous Coward · · Score: 0

      What level of experise does it take for a potential vulnerability and I stress potential vulnerability
        to be actually exploited?

      I think that we tend to think that vulnerabilties are absolutely exploitable and run too foolishly to coorrect them.

      Maybe so...but consider:
      If it takes an expert to cause an actual exploit and cannot be done by the average programmmers with nefarious intent ,
      Why should I care abouit vulnerabilities ?
      I am excul;sding memory leaks and other things that cause resources to be eaten up thoise are merly bugs

      For that matter a real expert can find vulnerabilities in any code. and that may be the secret to all of this hype
      I say hype because a vulnerabilty in no way means exploitable code .

    6. Re:Why Not? by Todd+Knarr · · Score: 3, Insightful

      "Package A leaks memory when used with package B? Package B needs to free the memory we allocate. Not our fault. *CLOSED*"

      Could be entirely legitimate to close it. If the spec says that package B shall take ownership of the memory when passed in, then yes a bug against package A for a memory leak should be closed and refiled against B that's not honoring the spec.

      "Package A has a buffer overflow vulnerability? Packages B and C must filter the strings they send us. Not our fault. *CLOSED*"

      Again possibly entirely legitimate. I've written a number of low-level routines that don't do much error-checking. This fact is explicitly noted in the API spec, and responsibility for error checking is explicitly placed on the caller. That's because these routines get used in performance-critical inner loops, and the error checking should only be done once outside the loop instead of every time the loop executes. That's easier to do if you hoist responsibility for the check up to the point where the data comes in, rather than pushing it down to the lowest level. But things like that do need to be spelled out in the spec, so users of that routine know what their responsibilities are.

    7. Re:Why Not? by nuntius · · Score: 1
      Even the article admits that a lot of these "issues" are trivial to fix:
      By far, the majority of the defects reported were null pointer dereferences (446 defects). A large number of defects resulted from the code not checking for null after memory was allocated.

      The code doesn't check for null after a memory allocation? Isn't the C++ standard to throw an exception instead of returning null when an allocation fails?

      I haven't dug through the Firefox code, but this smells like a non-issue their checker "finds" in order to tally more "defects".

      In addition, there were many cases where the return value of functions designed to return null were not checked prior to dereferencing.

      These sound like real bugs.
    8. Re:Why Not? by Anonymous Coward · · Score: 0

      Buffer overflow is a potential vulnerability

    9. Re:Why Not? by cheezit · · Score: 2, Insightful

      "any free testing is better than none"----I don't think so. Automated code scanning tools generally have a high false positive rate, and each possible bug must be examined thoroughly to identify what the issue is. Sometimes the change required to make the tool shut up will not have an impact on the behavior of the application, but now you have to test all the code paths because you changed the code.

      Free testing is great ONLY if the time spent investigating each problem is less than the time it would take conventional code defect work to get to the same level of quality.

      --
      Premature optimization is the root of all evil
    10. Re:Why Not? by Jerf · · Score: 3, Interesting

      If the GP is correct, it's still bad usage of the bug system. If Team A feels the fault belongs to Team B, the correct response is to move the bug to Team B, not to close the bug.

      They may get into a fight about whose responsibility it is, but such a fight is also a bug, as such responsibilities in such a large project basically are a part of the code and should also be clearly delimited. If you insist on using languages without automatic garbage management, "who's responisibility it is to deallocate this memory" is a fundamental part of the API.

    11. Re:Why Not? by ajs · · Score: 4, Insightful
      Rule #2 of security: there is no such thing as "mild security issues".

      This is unreasonable in the extreme. Security analysis is a matter of risk analysis, and to say that there's no such thing as a mild security issue is about the same as saying there's no such thing as a mild risk. Risks of all forms are multi-dimensional quantities, and yes it is possible to have a risk that is so mild that the trade-offs involved in fixing it are not worth the pain.

      Here's a great example: I can stand over your shoulder and watch you type your password to your 401k account in your browser. Firefox could address this "mild security issue" by having you pre-assign a dummy string which it removes from typed passwords. In any other browser that was not so configured the password you typed would fail to work, and the security problem would be greatly reduced.

      This is, however, not enough of an issue that it's worth it to firefox to take the lead in addressing it. Perhaps if some particular OS or desktop provided such an option as a user-level setting, then it would be worth picking it up and using it, but as it stands, there are bigger fish to fry.
    12. Re:Why Not? by drakaan · · Score: 1
      You and I haven't seen the details of the analysis, true. DO you suppose that someone would go through the trouble of finding all of those bugs and writing such a relatively glowing review of the software (imagine the tenor of the writeup, had it been a microsoft-funded expedition through the code) without giving the details to the developers?

      To me, this looks like a classic example of responsible disclosure...find bugs, inform devs specifically and the public generally and see what happens.

      With 611 defects and 71 security bugs, do you really think the developers can fix this in a timely manner? Do you really think they're going to fix them all?

      Well, with the line, file, and type of defect spelled out, I'd imagine it shouldn't take too long. If you've ever programmed before, you are probably familiar with building and then fixing based on the errors you run across. This is like writing a functioning Perl script and then adding "use strict;"...the problems noted might not break anything, but fixing them usually isn't too hard, and you know where they are.

      I guess, to answer your questions, I'd respond first by saying "Yes, I think they can probably fix this in a timely manner", and secondly by saying "If they don't fix them all, they'll give a list of reasons for leaving certain ones alone that we can argue about all over again".

      That's the beauty of open source, it works just like public works projects: put up a "Men at Work" sign in the summer and watch the years roll by.

      For minor projects, maybe so. I don't think Firefox is an example of an Open Source project that's languishing or lacking in development effort. You may have a different opinion, but then, you're an Anonymous Coward, so it's not as if it really matters.

      --
      "Murphy was an optimist" - O'Toole's commentary on Murphy's Law
    13. Re:Why Not? by Danga · · Score: 1

      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.

      I take it you don't work anywhere that has proprietary software otherwise you would not make such a claim. While some companies may have responses like that I doubt they would stay in business too long without their customers jumping ship. At the company I work at we review EVERY bug report sent in and then make sure the problem is fixed as soon as possible.

      Maybe where I work is a fluke, but I highly doubt that. Most developers worth a damn love to have people find bugs so they can fix them and make their software that much better.

      --
      Hey, there is only one Return and it's not of the King, it's of the Jedi.
    14. Re:Why Not? by Anonymous Coward · · Score: 0

      while the c++ standard wants new to throw, most compilers offer a way to have new return 0 instead, and mozilla tries to ask compilers to do this. it unfortuantely doesn't generally try well enough to work, but it does try.

      this partly relates to the fact that exception handling is hard and the exception handling implementations on most non microsoft platforms have been very expensive (basically borland wrote the patent or whatever and microsoft licensed it).

      so yes, in short new in mozilla should return 0 and it should be null checked. for the number of allocs in mozilla, the number of unchecked allocs is relatively small. otoh it is not small enough to not be a problem.

    15. Re:Why Not? by BalanceOfJudgement · · Score: 1
      The code doesn't check for null after a memory allocation? Isn't the C++ standard to throw an exception instead of returning null when an allocation fails?
      If the code in question is wrapped in a try-catch block, it could be a false positive.

      But then, I don't know the specifics of how the testing software determines if the code doesn't properly check for null - that is, I don't know if it also checks for the try-catch.
      --

      We are the fire that lights our world.. and we are the fire that consumes it.
    16. Re:Why Not? by RAMMS+EIN · · Score: 1

      ``This is unreasonable in the extreme. Security analysis is a matter of risk analysis, and to say that there's no such thing as a mild security issue is about the same as saying there's no such thing as a mild risk. Risks of all forms are multi-dimensional quantities, and yes it is possible to have a risk that is so mild that the trade-offs involved in fixing it are not worth the pain.''

      You're right, of course. However, if you already know about a vulnerability (or even a possible vulnerability) in your code, it's generally a good idea to fix it. It's happened all too often that an organization spent so much energy downplaying a security issue that it made me wonder if it wouldn't have been cheaper for them to fix it. Also, the impact of vulnerabilities is often underestimated (or the fact that they can be exploited isn't realized immediately). I'm sure you have seen advisories that upgraded the status of an earlier vulnerability, because a working exploit that took over affected systems had been detected. As long as these scenarios persist, I stand by Rule #2. Of course, you must still address the worst risks first.

      --
      Please correct me if I got my facts wrong.
    17. Re:Why Not? by Svartalf · · Score: 1

      The thing is WHOSE responsibility is it to check for it. Is it the responsibility of the
      code that is a performance loop and the data should already have been checked for sanity
      WAAAAY up above it? Nope. I think that was the point that the parent post was trying
      to make here. Yes, it's a potential vulnerability. Yes, it's a bug. But whose bug is
      it really? If the interface specifies that there's no checking (and I've
      done this regularly in code I've written over the years for performance reasons...) then
      that checking should be done above me, NOT everywhere all over the place.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    18. Re:Why Not? by Todd+Knarr · · Score: 2

      True, but often either package B isn't in the same bug-tracking system or team A doesn't have authorization to move the bug to someone else's package. I run into this all the time at work.

    19. Re:Why Not? by Jerf · · Score: 1

      True. I was assuming we were talking about Mozilla, which AFAIK has one bug tracker for all. check check check... yup, Mozilla and Firefox are both on bugs.mozilla.org. (Can't link though because slashdot links are banned.)

    20. Re:Why Not? by geekoid · · Score: 1

      "
      Rule #2 of security: there is no such thing as "mild security issues"."

      don't be daft, of course there is.

      Your rules clearly point to your ignorance of security.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    21. Re:Why Not? by avengex · · Score: 1
      "Rule #1 is that the only secure system is no system at all"
      Darn, I'm sick of everyone saying that. So, if you believe in that statement, why are you sitting at your computer right now?
      --
      http://www.avengex.com/
    22. Re:Why Not? by Dan+Farina · · Score: 1

      The point of your statement seems to be perspicuously absent.

    23. Re:Why Not? by RAMMS+EIN · · Score: 1

      Are you claiming my computer is secure? I don't have such illusions. However, I'm taking the risk because I think the benefits outweigh the costs.

      --
      Please correct me if I got my facts wrong.
    24. Re:Why Not? by Anonymous Coward · · Score: 0
      What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?

      And why wouldn't they?


      Not sure. But I have worked on bugs, pointed out not only the problem but the fix in the java code, and had my comments deleted from bugzilla because I'm not an "official" developer. So there is evidently a strong NIH going on there.

      I just did a report on bugs with "crash" or "hang" in the summary. For mozilla "core"
      • 180 unconfirmed
      • 575 new
      • 50 assigned
      • 22 reopened
      • 928 resolved
      • 1704 verified
      • 12 closed
      Look at bug 294645 reported 15 months ago. Someone gave a stack trace and indicated what the problem is. Think it will be fixed soon? Nope. Still marked "new".
    25. Re:Why Not? by Anonymous Coward · · Score: 0

      I knew someone with some 'Economics' background would chime in at some point.

      Are the factors of Risk involved in closed-source proprietary software the same for open-source software, even though there isn't a bottom line to be taken into account? I give you Microsofts history of bug fixing, vs the OSS community's history of bug fixing. Its a 'have to' vs. 'want to' relationship you're comparing here. Differentiated by a bottom line.

      It would seem to me that by its very nature, OSS does not play by the same rules that standard economics and risk analysis venture to churn out. Even with matters of security, OSS would seem better at determining a Risk : Security ratio than closed source, strictly from that fact that it can be more openly scrutinized, and consequently fixed.

    26. Re:Why Not? by jelle · · Score: 1

      By automatic source scanners, the code below most likely will be flagged as a potential security issue because it doesn't use strncpy(), but it isdn't because 'const s1' guarantees s2 can not be overflown. Sure, if somebody can poke around and change s1 using some other real security problem, using strncpy() here might help hide the real problem, but this code itself is not a security risk Actually, many compilers will see that the source is a const string and change it into a memcpy() anyway, removing even that.

      That's the thing about automatic source analysis.


      const char *s1 = "blabla";
      char s2[100];

      strcpy(s2, s1);


      --
      --- Hindsight is 20/20, but walking backwards is not the answer.
    27. Re:Why Not? by tomhudson · · Score: 1

      I'm sitting next to a totally secure computer.

      Its not plugged in, access to it is blocked by a big St. Bernard, there's no info on the hard drive, the video card and nic have been cannibalized.

      So yet, its possible to have total security. Just not practical.

    28. Re:Why Not? by ajs · · Score: 1

      Open source software doesn't "play by the same rules" in the sense that one cannot always direct effort, and thus risk analysis isn't going to be the driving factor for decisions as often as it would be in most singular companies that worked on a closed-source product, but that's misleading, since the sorts of risks that closed source companies deal with are often not based on criteria with which the majority of customers would agree.

      Your analysis of the ability for each type of organization to adequately assess risk, however, is probably not as useful as you think. There are practically infinite factors to be considered here. What happens when closed source companies have access to security information that open source companies would not? What about the situation where security bugs exist in tiny side-projects without nearly so many eyes?

      No, I think open source and closed source companies are on an equal footing in all but one respect: anyone who wants to can do a security audit of an open source product. That's the defining difference, IMHO.

    29. Re:Why Not? by ajs · · Score: 1
      It's happened all too often that an organization spent so much energy downplaying a security issue that it made me wonder if it wouldn't have been cheaper for them to fix it.

      I agree, and I think that a lot of the problem with security work these days is that the public has been so badly burned by that sort of problem that they are no longer even as rational as an uninformed public can be expected to be. That means that reasonable statements like, "X is a minor security issue," sound like a fire alarm to most consumers. That's a sad state of affairs.
    30. Re:Why Not? by Markus+Registrada · · Score: 1
      I doubt they would stay in business too long ... At the company I work at we review EVERY bug report sent in and then make sure the problem is fixed as soon as possible. Maybe where I work is a fluke, but I highly doubt that.

      Obviously you don't work at Microsoft. Their sales aren't affected by most bugs, so they don't fix most of them. Certainly there's no cachet in having fixed one. It was only after W2K or so that they began to get the idea that memory leaks might be a problem. Until then they figured the system would probably crash for some other reason before any leak or collection of leaks used up too much memory. They were more or less right. Maybe that was one reason not to fix crashes: without crashes they have to spend money fixing leaks, but people are already used to crashes.

      I still remember my astonishment at discovering, in 1998, that the word "crash" had mutated from "stops running, needs re-boot" to "stopped running, tried to re-boot, won't boot, needs re-install". I.e., "Windows has only crashed a few times, for me; I re-installed and everything was fine again."

      On Wall Street, any bug that doesn't cost millions in lost trading profits isn't considered worth bothering with. The time is better spent on features that yield millions, instead. No place in the world is friendlier to cowboy coders than Wall Street.

    31. Re:Why Not? by arth1 · · Score: 1
      "Package A leaks memory when used with package B? Package B needs to free the memory we allocate. Not our fault. *CLOSED*"

      Could be entirely legitimate to close it. If the spec says that package B shall take ownership of the memory when passed in, then yes a bug against package A for a memory leak should be closed and refiled against B that's not honoring the spec.


      No, the proper thing to do then is to either reassign it, or to open a new bug with the correct team and put the bug assigned to you as waiting for this one, so you can keep a track on when it's fixed, and follow up on behalf of the original bug poster if necessary. Closing ANY bug before the problem has been fixed is to shirk responsibility because you can get away with it. "It's someone else's fault" is never a reason to close a bug. If the problem can't be fixed by reassigning or opening a new bug, it must be documented very clearly, and the bug poster given a chance to accept this before closing the bug.

      Regards,
      --
      *Art
    32. Re:Why Not? by petermgreen · · Score: 1

      what if "package B" is a third party lib though?

      the only reasonable thing to do is to workarround even if its not your bug, because forcing everyone to upgrade the lib is often unfeasible.

      sadly many developers really do not wan't to pollute thier code with workarounds for third party problems even if there is no other reasonable way to fix the bug for thier users.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    33. Re:Why Not? by petermgreen · · Score: 1

      using try-catch to detect null pointer dereferences isn't really safe though, what if the code is used on a CPU without a MMU?

      maybe if you only target one CPU you can get away with this but its certainly very bad programming practice.

      ultimately automated flaw scanners are like compiler warnings, they WILL create false positives but they should at the very least be carefully considered.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    34. Re:Why Not? by avengex · · Score: 1

      It's hardly a risk if you know what you're doing. You'd need faith in your OS manufacturer if you wanted to run a system with no firewall or AV though ;)

      --
      http://www.avengex.com/
  6. Why not? by gstoddart · · Score: 4, Insightful

    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.
  7. Public knowledge is a good thing by with_him · · Score: 0

    In an era of scandal secrets I welcome the opportunity to make an informed decision. In that vein does anyone have comparable numbers for Opera, IE or other popular browsers?

  8. I value it by jimstapleton · · Score: 4, Interesting

    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"
  9. Better than the alternative by TheWoozle · · Score: 2, Interesting

    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.
  10. MS Security by Anonymous Coward · · Score: 2, Funny

    Right after they hired that Microsoft Security expert nevertheless!

  11. Eh? by Anonymous Coward · · Score: 0

    What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?

    Why would they not welcome this kind of analysis? If they truly try to tout themselves as one of the more secure web browsers, especially compared to IE, then they should welcome criticism of the security of their products. I'm not sure whether this is a biased or non-biased analysis, but it is definitely worth looking into on the part of the community.

  12. Answer: by Anonymous Coward · · Score: 5, Funny

    > 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?

  13. Of course! by dpaluszek · · Score: 0

    This will only make Firefox a stronger application on all of its builds, which means I feel confident using Firefox over its competitors. Remember everyone: FF > IE *flame suit on*

  14. Someone care to explain? by Anonymous Coward · · Score: 1, Funny

    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.

    1. Re:Someone care to explain? by ergo98 · · Score: 3, Informative
      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.

      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.
    2. Re:Someone care to explain? by DeepCerulean · · Score: 1
      Meh...a couple points:
      • Even though the vast majority of users may never expose a defect, it doesn't render the defect "irrelevant"
      • There is a huge difference (in terms of user experience) between shutting down gracefully (with a nice message and cleaning up after yourself) and crashing all over the floor when running into an "unrecoverable error"
      • Encouraging sloppy coding practices (even if they are becoming "normal development practice"), especially in a large scale project with a (relatively) transient support group, is begging to run into serious problems in maintaining the code down the road

      Personally, I think anyone who is even remotely serious about writing code should take (at the very least) a class on Software Engineering and spend some time learning about writing portable, easy to read, maintainable code with the mindset that you're probably not going to be the person fixing it when it breaks
    3. Re:Someone care to explain? by Todd+Knarr · · Score: 1

      If it's C++ code, there's another possibility. I use malloc() for byte buffers, but if you dig into the headers you notice something odd: the malloc() routine is actually a small macro that throws an exception if malloc() would return a null pointer. Back up in main() there's a catch block that catches all unhandled exceptions from the body of the program and terminates things as cleanly as possible. It'd be easy for a code analysis to turn up thousands of what look like unchecked memory allocations, but if they really would return NULL the check wouldn't ever get a chance to execute because of the throw.

    4. Re:Someone care to explain? by Todd+Knarr · · Score: 1

      I forgot, some people may not know another aspect of C++: operator new never returns a null pointer, so checks on it aren't needed. Operator new throws an exception if it can't allocate memory, the malloc() wrapper I described simply makes malloc() in a C++ program behave the way operator new would.

    5. Re:Someone care to explain? by eddy · · Score: 1

      >operator new never returns a null pointer, so checks on it aren't needed.

      Well, except if you use nothrow new, then.

      --
      Belief is the currency of delusion.
  15. Of course they do. by Anonymous Coward · · Score: 0

    Naturally the open source community appreciate this kind of analysis.

    Even if the original coders don't particularly care - there will be others who do and the entire reason the code was opened is so people could find these vulnerabilities and fix them.

  16. Great, get any help you can get. by DoktorTomoe · · Score: 1

    Seriously ... this basically is free work in finding bugs some user with less well-meant ambitions could have found and not reported.

  17. Well of course by Anonymous Coward · · Score: 0

    Why wouldn't it be welcome? Pretending that problems don't exist is a horrible way to produce software (or anything, for that matter). I really can't even think of why such a question would be asked.

    1. Re:Well of course by Anonymous Coward · · Score: 0

      Why wouldn't it be welcome? Pretending that problems don't exist is a horrible way to produce software (or anything, for that matter). I really can't even think of why such a question would be asked.

      Now a global network of nuclear plants running Firefox can be easily hacked into a simultaneous meltdown state due to this report and so we are all going to die horrible, suffocating deaths. Satisfied?

      Wait! What? Who would do this? Bin Laden's secret team of elite hax0rs, of course! They have a high-tech mountain somewhere on Afghanistan, just waiting for this opportunity! Oh, the humanity...

  18. HuH? by SirStanley · · Score: 1

    "What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?"

    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 /question to this story.

    --
    --------========+++Dont Feed The Lab Techs+++========--------
    1. Re:HuH? by Timesprout · · Score: 1

      I think the point being made is that the 'many eyes' mantra of many OSS developers can easily be challenged/questioned by running a few automatic checks over the code.

      --
      Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
      What truth?
      There is no dupe
  19. Of course it does by Dark+Paladin · · Score: 5, Insightful

    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.

    1. Re:Of course it does by cant_get_a_good_nick · · Score: 1

      My mother is a fish.
      Thank you Vardaman. Wait, what are you doing with that drill.....

  20. False positives by interiot · · Score: 4, Informative

    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.

    1. Re:False positives by LWATCDR · · Score: 1

      I did notice that a lot of the errors involved assuming that an malloc didn't return null.
      While really bad practice it should only happen when a system runs out of virtual memory. If you get to that point the only real answer often is to terminate the program or abort the the current operation depending on what caused the error. If you do not detect the situation and try and use a NULL pointer you get a GPF which will terminate the program. Such a situation should be very rare and effect very few users. Now in the embedded space this is deadly. On a desktop it isn't likely to happen often, if ever.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    2. Re:False positives by Reziac · · Score: 1

      That's very interesting, because Mozilla v1.00 is the only program that has ever caused a BSOD on my generally-bulletproof Win95 box; I no longer recall the details, but it was repeatable. Now I'm wondering if it was due to an incident such as you describe.

      --
      ~REZ~ #43301. Who'd fake being me anyway?
    3. Re:False positives by Anonymous Coward · · Score: 0

      When I evaluated Klocwork a while ago I ultimately ended up assuming that every thing it reported was a bug in Klocwork until proven otherwise. It is very easy to make a tool that whines a lot, which seems to be the path they took. It looked like they never even did intra-procedural analysis. eg they would claim that a parameter could be null. I'd have to manually check every caller (and often their callers) to verify that null could not in fact be passed in. That is the sort of analysis the tool should do.

      Although both Klocwork and Coverity scan open source projects for free, they only do so for major works such as Samba or X. Small libraries or programs such as libusb aren't on their radar. Unfortunately the free tools seem to have stagnated - eg smatch was last updated 3 years ago.

      http://en.wikipedia.org/wiki/List_of_tools_for_sta tic_code_analysis

    4. Re:False positives by LWATCDR · · Score: 1

      "generally-bulletproof Win95 box;"
      Win-95 was never bulletproof. But yes accessing a null pointer in Win95 could probably result in a BSOD. It is about the most common error in programing and shouldn't cause a system crash in any memory protected OS. But then I once found a .txt file that when you used the type command to display it would BSOD windows 2000 and XP which should also be impossible.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    5. Re:False positives by Anonymous Coward · · Score: 0

      I think they should file a bug report against Klockwork to fix the false positives, and run it again. The more we improve our analysis software the better our ability to find/fix bugs will get. I love running this kind of analysis software on code I'm working on because I know that once all the issues are fixed, I'll be that much closer to perfection (an unobtainable goal, yes, but one definitely worth reaching for).

    6. Re:False positives by Reziac · · Score: 1

      Sure, there are always stupid bugs and holes that get overlooked until some creative person tries weird stuff like that... once the problem is discovered, it seems way too obvious, but it must not have been at the time, or it wouldn't exist. IANAP, but I expect copy-and-paste code leads to a lot of such issues.

      (I'm widely-feared as "the beta tester who can break anything" cuz I'll do what seemed obvious to me, but that the coder never thought of :)

      --
      ~REZ~ #43301. Who'd fake being me anyway?
  21. Costs and motivations by kjs3 · · Score: 4, Insightful
    What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?

    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.

    1. Re:Costs and motivations by MalusCaelestis · · Score: 1

      You're wrong. Open-source developers' time is finite, which means they must prioritize. Bugs that affect security (should) get handled first, followed by bugs that affect primary components (thus affecting most users), followed by bugs that cause those little quirks we all love to hate.

      In this prioritization process, a bug that will affect nearly every user gets handled fairly quickly. But a bug that only affects, say, one percent of the users will take quite a while longer. And if there's a bug that affects one user in 10 million and would take a week of a developer's time, it's just never going to get fixed because there are always more important bugs developers could be working on.

      Open-source projects may not have to worry about the bottom line, but the prioritization is the same because both open-source projects and closed-source projects have a finite resource. With an open-source project, that finite resource is developers' time. In a closed-source project, the finite resource may LOOK like money, but that money only buys developers' time by hiring the developers.

      So the question isn't "What will this do to my bottom line?" but rather "What is the best use of my developers' time?"--a question that both open-source and closed-source projects have to ask.

  22. Very responsive... by whiskeyriver · · Score: 1

    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.
  23. Know your weaknesses by Jazzer_Techie · · Score: 1

    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.

  24. Great Opportunity by desNotes · · Score: 1

    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
    1. Re:Great Opportunity by CastrTroy · · Score: 1

      Since when is Opera open source?

      --

      Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
    2. Re:Great Opportunity by SEMW · · Score: 1

      Exactly. It's interesting how everyone in Slashdot seems to treat Opera as a kind of 'honourary open source' browser: look at all the threads above using TFA to expound the advantages of open source by favourably comparing Firefox to IE. This is hardly a fair comparison of open source to closed source in general, Microsoft being Microsoft. None on them, you note, compare Firefox to Opera, arguably a much more fair comparison -- but one that would rather invalidate their argument, since, in my experience, Opera is far more stable and bug-free than Firefox. (Not, of course, that I'm detracting from the open-source model -- I really do think it's a wonderful concept and highly admire those who work in it).

      --
      What's purple and commutes? An Abelian grape.
    3. Re:Great Opportunity by desNotes · · Score: 1

      I was adding at the end of my post that in addition to FireFox, I would pay to use Opera, not to infer that Opera is open source. I am not an open source bigot. I appreciate good apps. I believe FireFox is a good product and heartedly agree that the feedback given it will make it an even better product.

      I like Opera also as it is faster and has a smaller footprint than FireFox. For the open source project I am working on, it fits better than FireFox. On my desktop at home I use both FireFox and Opera and at work primarily FireFox except for our company Intranet which forces us to use IE.

      I use what is best for the job and appreciate good workmanship. As a business model I think open source is the way to go but it doesn't cover everything and I wouldn't limit myself to only using open source products...but that's just me.

      --
      "Saying that Linux is inferior to Windows because more people use Windows is like saying that all restaurants are inferi
  25. Incomming by Ajehals · · Score: 1



    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?

  26. The only issue I can see by tygt · · Score: 1

    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.

  27. Copy, paste by Jon+Peterson · · Score: 4, Funny

    Hey, if it makes them fix the copy/paste bug, it's all good by me.

    --
    ----- .sig: file not found
    1. Re:Copy, paste by Reverend528 · · Score: 3, Funny
      Hey, if it makes them fix the copy/paste bug, it's all good by me.

      Hey, if it makes them fix the copy/paste bug, it's all good by me.
    2. Re:Copy, paste by Alsee · · Score: 1
      3ɉ(TM)8¿7‹&#1 4;(TM)83Ò‰6›8ÿz7‰ (TM)8=
      Hey, if it makes them fix the copy/paste bug, it's all good by me.

      -
      --
      - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
    3. Re:Copy, paste by julesh · · Score: 1

      THANK YOU.

      I've been spending the last year or so assuming I was crazy, thinking to myself "I'm sure I pressed Ctrl+C." I was on the edge of concluding that the control key on my keyboard was slightly dodgy.

  28. One would certainly hope so... by tcopeland · · Score: 4, Interesting

    ...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.

    1. Re:One would certainly hope so... by psykocrime · · Score: 1

      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.

      I have no mod points, but I give you a "virtual" +1 on that.

      --
      // TODO: Insert Cool Sig
  29. Tools like this produce lots of false positives by Jimmy_B · · Score: 5, Informative

    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.

    1. Re:Tools like this produce lots of false positives by Smack · · Score: 1

      And then someone less experienced copy & pastes that code to somewhere else where the same assumptions don't hold, and you have a memory leak out of nowhere.

      Woo.

    2. Re:Tools like this produce lots of false positives by onehundredandfive · · Score: 1

      From the article (response to similar critique; see comments in original article):

      "Regarding Alec Flett's post I just want to clarify the methodology I used for this analysis. Although this analysis was automated (machine generated) the level of analysis is more sophisticated then a traditional lint-type tool. Klocwork and other modern static analysis tools are breaking the common misconception that these types of tools are noisy. In fact, the most crucial advancement in the static analysis field is the significant improvement in the signal-to-noise ratio, making it an efficient use of the developer's time.

      In this particular analysis we reviewed the entire results to verify the correctness of the defects. For example, to address Alec's point about XPCOM refcounting, we did account for that in the analysis. As I mentioned in my post, as with any analysis only the developers can be the final judge on the severity of these problems."

    3. Re:Tools like this produce lots of false positives by Zoxed · · Score: 1

      > tend to produce lots of false positives, because they can't make as many assumptions as a programmer who knows what's going on

      What is it they say about assumption being the mother of all f**k ups ? !!

      What you say is true, but, assumptions *do* create problems during maintenence. People do cut and paste code around, change code logic etc. OK, they should check properly what they do, but it does not always happen and if you bulletproof your code then you can reduce the risk. Of course there is an overhead in code size/performance :-(

    4. Re:Tools like this produce lots of false positives by Aapje · · Score: 1
      That doesn't have to be true. There are programming constructs that are just wrong, no matter what the interactions are. If a static analysis tool finds such a problem you always have to fix it, since there is no justification for it. An example:
       
      if (str==null && str.equals("")) { show an error }
      This code crashes when str is null, since the equals method will be incorrectly called on a null object. There are two possible fixes:
      1. If you know str can never be null, remove the null check.
      2. Otherwise, change && into ||. This is the correct fix if str can actually become null.

      Aside from the detectors that are 100% right, there are also those that have very low false positive rates. If you only use these kinds of detectors for analysis, you can compile a list with very few bogus bugs. For instance, we use static bug analysis in the build process of our web application (for a national telecom company). The build fails if the static analyser finds a problem. With a tuned set of detectors, almost all failures are the result of bad code and only very seldomly will a detector be turned off for a certain line of code because it was a false positive.
      --

      The Drowned and the Saved - Primo Levi
  30. Speaking of which... (Was Re:Obvious.) by Billosaur · · Score: 5, Insightful

    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
    1. Re:Speaking of which... (Was Re:Obvious.) by Danga · · Score: 1

      The numbers look large given that Firefox is supposed to be the superior browser

      Opera is the superior browser at the moment performance/standards compliant wise.

      Think Gates & Co. would care to give up the source code to do a head-to-head comparison?

      Of course they wouldn't, but I would love to see a comparison against Opera.

      --
      Hey, there is only one Return and it's not of the King, it's of the Jedi.
    2. Re:Speaking of which... (Was Re:Obvious.) by rucs_hack · · Score: 5, Interesting

      slightly OT I know, but relevent:

      Back when I was a nurse, in the days before programming sucked me in, I was a manager in a private elderly care home for people with dimentia.

      We kept excruciatingly detailed records of every scratch, cut and injury, serious or otherwise, that happened to our clients. So much so that on paper our accident record look awful compared to other homes, who tended not to be so open. We actually had fewer such incidents then other homes in our region, but we documented *everything*.

      However, come official inspection day, the health authority inspectors were always very pleased with our records, and always passed us with a very high grade.

      The reason? Instead of hunting around for hidden evidence that had been concealed, they just had to consult our records.
      We were open about problems, and always sought solutions. We were also, because of our policy on recording everything, able more easily to identify problems with patients who were more likely to get cut, and work to alter their environment or diet to try and help.

      The result was that we ended up being the top specialist care home in our region.

      When I moved into computer science, the only software model that I would work with was open source. Again there is nothing gained from hiding problems with code, and it's much easier to identify issues. I discovered remarkable similarities with my old nursing practices and the Open Source method.

      I realise the comparison may seem odd, but my point is that being open about problems is a far better way to reach solutions, whatever field it is applied to.

    3. Re:Speaking of which... (Was Re:Obvious.) by ScrewMaster · · Score: 4, Insightful

      I realise the comparison may seem odd, but my point is that being open about problems is a far better way to reach solutions, whatever field it is applied to..

      That is actually an excellent example (and hardly off-topic) but in that case as well as software development, it only works when those responsible are actually interested in finding solutions. Far too often the goal is simple suppression of any negative information. That can be for any number of reasons, but true openness requires a degree of, well, maturity that is in rather short supply nowadays. It doesn't help that there are thousands of hungry attorneys out there just waiting to pounce on any misstep (from a purely legal perspective, honesty is not necessarily but the best policy.)

      --
      The higher the technology, the sharper that two-edged sword.
    4. Re:Speaking of which... (Was Re:Obvious.) by pixel_bc · · Score: 1

      > Back when I was a nurse, in the days before programming sucked me in, I was a manager in a private elderly care home for people with dimentia.

      Might be tasteless, but my current job and your former job somehow feel similar.

    5. Re:Speaking of which... (Was Re:Obvious.) by Anonymous Coward · · Score: 0

      Of course they wouldn't, but I would love to see a comparison against Opera.

      That puts us in a tiny minority. 99% of the slashbots wouldn't.

    6. Re:Speaking of which... (Was Re:Obvious.) by Anonymous Coward · · Score: 0

      >I'll bet the folks in Redmond are looking at these numbers and wondering just how to get IE's numbers that low.

      Not really. They've had similar tools internally for years. They aren't a magic bullet.

      Nice troll, though. I'm sure you'll be modded to +5.

    7. Re:Speaking of which... (Was Re:Obvious.) by Mister+Whirly · · Score: 1

      I know the feeling all to well. I tried to explain the same concept to a friend of mine who taught elementary school - I told her that I did a hell of a lot more "babysitting" and "hand holding" as a programmer than she did as a teacher.

      When designing a foolproof system, never underestimate the ingenuity of fools. (or the stupidity of the users)

      --
      "But this one goes to 11!"
    8. Re:Speaking of which... (Was Re:Obvious.) by Zantetsuken · · Score: 1

      Sure standards are great, but does EVERY web-designer and developer out there write to standards? Of course not, I'll bet you that even a few major sites aren't up to standards - so when people take Opera for a test drive, and it doesn't display Yahoo or whatnot properly (just because the Firefox and Opera users on /. know Yahoo sucks, doesnt mean the rest of the world's Firefox and Opera users do), they are going to not use Opera...

      So even though it would be great to live in a standards compliant world, it probably won't happen any time soon - so you have to make the browser in question (Firefox, Opera, whatever) also NON-standards compliant so that the page doesnt have layout tables shifting rows and columns around...

    9. Re:Speaking of which... (Was Re:Obvious.) by T.E.D. · · Score: 1
      When I moved into computer science, the only software model that I would work with was open source. Again there is nothing gained from hiding problems with code, and it's much easier to identify issues. I discovered remarkable similarities with my old nursing practices and the Open Source method.


      Care to try moving into government next? Please?
    10. Re:Speaking of which... (Was Re:Obvious.) by Danga · · Score: 1

      So we are in the superior 1% of web browser users!

      --
      Hey, there is only one Return and it's not of the King, it's of the Jedi.
    11. Re:Speaking of which... (Was Re:Obvious.) by Anonymous Coward · · Score: 0
      Opera is the superior browser at the moment performance/standards compliant wise.

      Which must explain why, the last time I used Opera, it broke on almost every JavaScript it tried to load.

    12. Re:Speaking of which... (Was Re:Obvious.) by no_space_in_time · · Score: 1

      You say dimentia, I say dementia. Great analogy though.

      --
      "save a cow, eat a vegetarian"
    13. Re:Speaking of which... (Was Re:Obvious.) by Anonymous Coward · · Score: 0
      So we are in the superior 1% of web browser users!

      Oh, sage Brother Opera-User, why doth thou even endeavor to communicate with the unwashed masses of such minsicule intellect? Doeth they amuseth thou in some way?
    14. Re:Speaking of which... (Was Re:Obvious.) by Politburo · · Score: 1

      Well, now we know how to circumvent an inspection. Keep detailed records of minor incidents, and cover-up the major ones :)

    15. Re:Speaking of which... (Was Re:Obvious.) by Temujin_12 · · Score: 1

      patients who were more likely to get cut, and work to alter their environment or diet to try and help.

      Wow! Altering their diet prevented them from getting cuts? What kind of food were you feeding them!?

      --
      Faith is a willingness to accept something w/o complete proof and to act on it. Reason allows you to correct that faith.
    16. Re:Speaking of which... (Was Re:Obvious.) by AlastairH · · Score: 1

      Not strictly speaking the point, its not a p***ing competition after all, a FF user doesn't really care how many mistakes there are in IE because he/she isn't using it... Of course the community should welcome this, then the community can work on it rather than the man hiding behind closed doors assuring us he's working on it.

    17. Re:Speaking of which... (Was Re:Obvious.) by Durzel · · Score: 1

      Who's to say that they would definitely get numbers that high? That's pretty big speculation on your part really, even by typical anti-Microsoft standards.

      I use Firefox both at home and work and I think these results just go to show that no software is by definition bug-free, regardless of whether it is open or closed source. People who automatically believe that because Firefox is the community favourite and open-source that it is naturally superior (in code terms) are deluding themselves.

    18. Re:Speaking of which... (Was Re:Obvious.) by Stringer+Bell · · Score: 1

      I'll bet the folks in Redmond are looking at these numbers and wondering just how to get IE's numbers that low.

      That is some beautiful spin right there. Have you considered a career in politics?

    19. Re:Speaking of which... (Was Re:Obvious.) by rucs_hack · · Score: 1

      elderly people's skin can become more frail if they don't receive enough fluid, or their vitamin intake is too small, or, as is more often the case, their diet changes and their body can't cope.

      We used to prescribe fried breakfasts, no really, I'm not kidding, we did, it worked really well. Our chef had lists from me of what I felt individual people could do with, and their fry up was adjusted accordingly.
      Or some people would have those nasty vitimins and minerals hidden in ice cream so they'd eat it.

      You'd be amazed what difference diet makes to the quality of skin in the elderly, and yes, incidents of skin damage decreases as skin pliability increases.

      It's all about attention to detail.

    20. Re:Speaking of which... (Was Re:Obvious.) by d_jedi · · Score: 1

      The analogy doesn't really work that well.. because the source code of a computer program is really the crown jewels for any software company. If that's out in the open, you can't control who will use your software, legally or illegally.

      For some areas, notably custom software with a limited appeal to the general public, the open source model makes sense.. but for most software products, it doesn't make sense - they'd probably go out of the business of selling software if they open sourced their stuff.

      --
      I am the maverick of Slashdot
    21. Re:Speaking of which... (Was Re:Obvious.) by ebyrob · · Score: 1

      The problem with open source, as it is most often used in modern parlance, is that you don't just allow people access to your inner workings. You wind up giving away all of your software for free. At least, that's true if you're talking about open source in the Apache/BSD/GPL sense.

      Most likely this is because if you gave source only to your customers, they wouldn't be in a position to do much with it anyways... For example, many years ago the company I work for used to give source to all of their customers for software they purchased, but it was never called "open source".

      It certainly would be interesting to see modern companies give out source without also providing those products for free to anyone who asks, but it doesn't appear a common business practice. (Not that giving away code doesn't work in many situations, just that it is a pretty big leap to take from a more proprietary model where you expect to use the copyright system to extract a bit of remuneration...)

    22. Re:Speaking of which... (Was Re:Obvious.) by oSand · · Score: 1

      Given the number of rendering bugs (bugs, not compliance WTFs) observable in IE compared to those in Firefox, it'd be a rather safe assumption. Also, the download for IE is 25 fcuking meg. More code = more bugs. Besides, after developing for it for a while you just know, you just fcuking know.

    23. Re:Speaking of which... (Was Re:Obvious.) by BiggyP · · Score: 1
      Well i'm looking forward to seeing how things pan out with Xara Xtreme, there's an example of open sourece software which isn't actually given away free, for the windows platform at least. X-chat takes a similar approach and is despised for it, i should imagine it also reduces its adoption considerably among windows users. QCad started charging for win32 builds quite some time ago and i suppose it must be working out for them.


      The one thing that a company can always sell even if they give the product away for free is commercial support, that's the kind of thing that keeps redhat and novell in business.

  31. 71 potential security vulnerabilities? by Anonymous Coward · · Score: 0

    Is this going to be potential off by ones and buffer overflows or are their tools better than that?

  32. Oh yeah, they welcome it by Anonymous Coward · · Score: 0

    by telling them 'Fix it yourselves, it's open source.' In the end, it is no different than closed-source to those that can't code.

    1. Re:Oh yeah, they welcome it by shani · · Score: 1

      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.

    2. Re:Oh yeah, they welcome it by Anonymous Coward · · Score: 0

      Yeah, by paying hundreds of dollars. Hell, might as well stay with Microsoft Internet Explorer. At least it is stable. The only reason why Firefox is secure is it crashes every other hour. I have tried it and that is what it does, even after a clean install and no extensions.

    3. Re:Oh yeah, they welcome it by Anonymous Coward · · Score: 0

      Wow, you are obviously too stupid to even exist let alone use a computer. If you really are sick of the rightful attitude of the Open Source movement, here is what you can do to so it won't bother you anymore.
      Go find a cliff or a bridge somewhere, then take your entire fucktarded family.
      Have all of the jump off to their deaths. After that, jump to yours. Now you won't have to put up with the attitude anymore and there will be a lot less fucktards we have to put up with constantly bitching about open source.

  33. I kid you not... by PFI_Optix · · Score: 4, Funny

    Firefox just crashed while I was reading this article.

    --
    120 characters for a sig? That's bloody useless.
  34. Watch for IE Fanboys by just_forget_it · · Score: 1, Flamebait

    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.

    1. Re:Watch for IE Fanboys by MechaShiva · · Score: 2, Funny

      Que the crickets...

      --
      After calming me down with some orange slices and some fetal spooning, E.T. revealed to me his singular purpose.
    2. Re:Watch for IE Fanboys by MechaShiva · · Score: 1

      It's 'Cue' you idiot. Learn to preview your posts... (oops)

      --
      After calming me down with some orange slices and some fetal spooning, E.T. revealed to me his singular purpose.
    3. Re:Watch for IE Fanboys by Danga · · Score: 1

      "Que" is an easy typo for coders, I don't think you are an idiot but previewing definitely is good to do! :-)

      --
      Hey, there is only one Return and it's not of the King, it's of the Jedi.
    4. Re:Watch for IE Fanboys by SnowZero · · Score: 1

      Maybe he meant queue? Crickets lined up in an orderly circular buffer seems nice to me. Then again, I'm a programmer.

  35. Not too bad by dctoastman · · Score: 4, Insightful

    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.

  36. Of Course (and I'll jump for the bait) by DragonFodder · · Score: 1

    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.
  37. Full disclosure is the way to go by bob+whoops · · Score: 2, Insightful

    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.

  38. Mod the submitter -1 troll... by Chaffar · · Score: 1
    What are your thoughts -- do Firefox and the open source community welcome this kind of analysis?
    What a way to get people to respond to a no-news article. Open-source project has bugs and vulnerabilities. Oooooh, what a shock. And I thought the source code of FF was handed to us by Moses himself :(
  39. College Lab by ThreeDeadTrolls · · Score: 2, Interesting

    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.

  40. self-serving to announce it by Anonymous Coward · · Score: 0

    Going public with something like this when it is already in the hands of the developers seems somewhat self-serving. As far as I can tell there are no verified security holes. As a developer I would be annoyed.

  41. The Beauty of Open Source by Rachel+Lucid · · Score: 1

    ... 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.

  42. 2.0 Beta 2 by Paul+Slocum · · Score: 0

    sure, but why are they looking at 1.5.0.6 when 2.0 beta 2 is out? I switched to 2.0 beta a while ago because of annoying bugs in 1.5.x that were fixed in 2.0.

    1. Re:2.0 Beta 2 by Anonymous Coward · · Score: 0

      most of 2.0 was a ui refresh, while that did include some new code which probably has new bugs, it's not a drastic change. what they should have analyzed was trunk, which has been receiving coverity fixes for over a year now (1.5 is well over a year old as branches go). coverity is of course a static analysis tool.

      the result is that while i haven't seen the actual reports from this guy, i'm not sure it's worth my time to look, if most of them are fixed already, and most of them overlap with the ones coverity reported.

      coverity says there are 435 defects that it knows about in trunk. on 2006-Apr-07, it knew of 706.

      my guess is that the 611 are mostly a subset (possibly a proper subset) of the ones coverity has been reporting. which means this report is pretty much useless.

      having read through other similar analysis tools before using coverity, namely flaw finder, which really was a huge waste of time, i'm really not sure i want to look through Klocwork's results.

      this would be kind of like offering a review of the linux 2.2 kernel.

      According to bonsai.mozilla.org, checkins to module MozillaTinderboxAll since 2005-08-12 00:00 :
      Changers: 292 people
      +871161/700847 Lines changed

      This isn't to say that I do not welcome reports, but reports should be against either trunk, or the ff2.0 branch as you mention. reports about fixed bugs do not help us. just like multiple reports of the same news item to slashdot really aren't helpful. they divide time and waste energy.

    2. Re:2.0 Beta 2 by Anonymous Coward · · Score: 0

      I dunno, maybe because 2.0 beta 2 is a beta version, expected to have more bugs than a release version?

  43. which one of those bugs was the by Loco3KGT · · Score: 4, Funny

    "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.
    1. Re:which one of those bugs was the by ThePlague · · Score: 5, Funny

      That's not a bug, it's a feature.

    2. Re:which one of those bugs was the by Anonymous Coward · · Score: 0

      wow - I can't believe your attention span is so long!

    3. Re:which one of those bugs was the by Reziac · · Score: 1

      I never go to Myspace [g] but... what sort of problem does it generate?

      I'd expect, given Myspace's HTML, that it tickles the old Mosaic bug where certain structures (notably links that display a lot of text in the link itself, and flash placeholders) *inside* table cells cause a resource leak -- sometimes drastic. [Also happens in some builds of Netscape, Mozilla, and yes, even IE]

      Side note: I've documented this problem in several browsers, but still couldn't get anyone interested in fixing it. :(

      --
      ~REZ~ #43301. Who'd fake being me anyway?
    4. Re:which one of those bugs was the by jb.hl.com · · Score: 1

      That's not exactly hard, considering it takes about 10 minutes just to load the homepage, and logging in takes another 10.

      --
      By summer it was all gone...now shesmovedon. --
  44. Re:Oh noez by Anonymous Coward · · Score: 0

    I'm not sure why your post was moderated up at all. 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.

  45. For one who works in QA this doesnt bother me.... by Thrymm · · Score: 4, Insightful

    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....

  46. bugs != exploits by no+reason+to+be+here · · Score: 2, Insightful

    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.

    1. Re:bugs != exploits by gogogadgetearl · · Score: 1
      security vulnerabilities are a subset of software bugs.
      I would disagree. Security vulnerabilities can derive from poor logic as well as software bugs. They shouldn't be generalized in either way.
    2. Re:bugs != exploits by GrievousMistake · · Score: 1

      He said 'at best'.

      --
      In a fair world, refrigerators would make electricity.
    3. Re:bugs != exploits by onehundredandfive · · Score: 1

      The article does not conflate defects and security risks. It clearly separates them: "The analysis resulted in 655 defects and 71 potential security vulnerabilities." Some security vulnerabilities can fall directly under the 'software bug' or 'defect' umbrella while others can be found off roaming in fields of coding semantics and input validation routines. The difference is subtle and subjective. Also, in the article, the 655 defects are broken down into sub-categories and probably 'Security Vulnerabilities' is just another category but it is a better attention grabber. Cheers.

  47. Re:I think... by Anonymous Coward · · Score: 0

    i feel sorry for you; the future of IE: IE7 takes much longer to load than firefox.

    i uninstalled ie7 and put ie6 back. ie6 had a good UI. ie7 sux.

  48. Coverity already did a scan by alanjstr · · Score: 3, Informative

    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.

    1. Re:Coverity already did a scan by Anonymous Coward · · Score: 0

      Exactly and now Klockwork wants to get in on the game since their marketing gurus were too stupid to do this first!!!

  49. Re:I think... by wirah · · Score: 0

    "and that everything is layed out differently. Not too differently, but different enough that I want IE back." I think you mean laid. Have you not noticed then that you can click 'customize...' and move everything about? You probably don't like firefox because you've never really "used" firefox. It's a very decent browser, and I used to really like IE. Its your choice if you like IE or not, but bear in mind that microsoft deliberately make it nonstandard, and leverage their monopoly to get their own "standard" on the web, which is indeed a very evil and incorrect way to go about things. 52% compatibility? Forget it. Standards are an excellent thing and I cannot tolerate any person or company who decides to break them on purpose.

  50. Security reviews are _the_ push for OSS by msobkow · · Score: 5, Insightful

    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.
    1. Re:Security reviews are _the_ push for OSS by ronanbear · · Score: 2, Insightful
      As long as the vulnerabilities aren't disclosed publicy without allowing the developers the chance to decide what to do they should be very happy.

      This audit/analysis has tracked down bugs and problems that might have taken a much longer time and much more effort to find. Now developers time can be spent fixing problems instead of finding them (which they should still do, naturally).

      --
      the more they over-think the plumbing the easier it is to stop up the pipe
    2. Re:Security reviews are _the_ push for OSS by msobkow · · Score: 2, Insightful

      It's OPEN SOURCE.

      The vulnerabilities are there for anyone to find, so not disclosing the results in a reasonably short time frame so they can be fixed would be irresponsible. Hiding vulnerability reports is only advantageous to closed source, where the crackers can't see the problematic code.

      --
      I do not fail; I succeed at finding out what does not work.
    3. Re:Security reviews are _the_ push for OSS by bunratty · · Score: 1

      Making vulnerability reports public makes vulnerabilities easier to find and thus makes it more likely for them to be exploited. Security bugs should be reported privately, by checking the "This is a security problem that should be kept confidential until addressed (security policy)" checkbox when filing a bug in Mozilla software. And remember, if you're the first to report a security bug in Mozilla software (whether you check that box or not), you get a $500 Security Bug Bounty.

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    4. Re:Security reviews are _the_ push for OSS by SuperMog2002 · · Score: 1

      Yes, they're there for anyone to find, but posting them on a public forum allows many trouble makers who would have never found the flaws otherwise to exploit them. The bugs should be disclosed to the developers so that they can be fixed, but announcing them publicly, at least right away, would be irresponsible.

      --
      Sunwalker Dezco for Warchief in 2016
    5. Re:Security reviews are _the_ push for OSS by dextromulous · · Score: 1
      The bugs should be disclosed to the developers so that they can be fixed, but announcing them publicly, at least right away, would be irresponsible.

      Generally, those "irresponsible" people follow the Full Disclosure Philosophy and do so because (for reasons that may or may not be valid) they do not feel they would get results otherwise.

      --
      There are two types of people in the world: those who divide people into two types and those who don't.
    6. Re:Security reviews are _the_ push for OSS by SlOrbA · · Score: 1
      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.

      and there is this wonderful license "as is" policy, that in big companies cuts the need for license negotiations (and the time to market). In big volume products the licensing issues can be more time consuming than the actual development.

    7. Re:Security reviews are _the_ push for OSS by zCyl · · Score: 1
      And remember, if you're the first to report a security bug in Mozilla software (whether you check that box or not), you get a $500 Security Bug Bounty

      At 71 vulnerabilities, that could start to add up to some real money... Is there a quantity limit?
    8. Re:Security reviews are _the_ push for OSS by bunratty · · Score: 1

      Not that I know of. Last year someone got paid $2500 for five vulnerabilities he found. And remember there are 71 "potential" security vulnerabilities. I'm sure there are plenty of false positives in there.

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    9. Re:Security reviews are _the_ push for OSS by Dirtside · · Score: 1

      That's why the proper method is to alert the developers privately first. Give them a short amount of time to find, fix, and release a patch or new version. If they haven't done it in a reasonable time (usually 3-10 days, depending on the severity and complexity of the bug), then you announce it publicly.

      --
      "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
    10. Re:Security reviews are _the_ push for OSS by Anonymous Coward · · Score: 0

      That it can be inspected, reviewed and fixed are the reasons I've heard for NOT using OSS.

      Why? Being open source implies a lack of trust of the author or company. It implies that there are faults that need fixing, and that perhaps it's just amateurs goofing around.

      I know. I know. This is crap. This is what my boss was telling me. He'd rather work with a Microsoft where he has zero access to source, because he trusts that a big software company would have a better grip on its own code and would be professional in all all aspects of their product. He also felt that professionals made fewer mistakes so there was no need for open source.

      To him, the very fact that someone would be open with their code meant that it wasn't professional enough. So our company went with IIS/NT4 instead of Apache/linux, got hacked, lost a crapload of client files (deleted to make room for a rooted file sharing Napster-type thing) and loss of key clients eventually doomed the company.

      Company owners would regularly attend tradeshows and come back with thousands of dollars of software they picked up at the show, and it was always stuff written in VB (because they LIKED the VB look and feel "just like Windows!" they said) and force this junk on the poor workers. I finally gave up and wrote something in VB for them, got it working just fine, printed out the code and stamped OPEN SOURCE on it and turned in my badge and keys and walked out. I was told they stopped using the program a week later. Poisoned! Tainted by the OSS tag. What a riot.

  51. Disable-Output-Escaping by jkeegan · · Score: 3, Interesting

    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
    1. Re:Disable-Output-Escaping by Ant+P. · · Score: 1

      And I don't blame them for ignoring it, that bug's even more of a trollfest than the MNG bug.

    2. Re:Disable-Output-Escaping by sTeF · · Score: 1

      what about the solution posted on
      http://forums.mozillazine.org/viewtopic.php?t=1369 81
      doesn't this solve the problem, or did i not grasp the bug?

  52. Firefox a little bit more bloated than it used to? by zwilliams07 · · Score: 1

    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.

  53. Many eyes... by eltoyoboyo · · Score: 1

    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
  54. Halting problem revisited? by bugnuts · · Score: 1

    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? :-)

  55. Good deal by PenguinX · · Score: 1

    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.

    1. Re:Good deal by Reziac · · Score: 1

      And this points at places for those eyes to look, where otherwise maybe no one would have bothered.

      --
      ~REZ~ #43301. Who'd fake being me anyway?
  56. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  57. The more the merrier by thorkyl · · Score: 1

    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...
    1. Re:The more the merrier by Anonymous Coward · · Score: 0

      I love criticism, it makes me stronger.

      Cool! You're ugly and your mother dresses you funny.

      You're welcome.

  58. They're not "irrelevant bugs". by Anonymous Coward · · Score: 0

    No, those are not "irrelevant bugs". They're examples of very sloppy coding. Unfortunately, it is the type of coding that the Mozilla project is becoming known for.

    And we're not in the "era of seemingly limitless virtual memory". It's not uncommon for typical desktop users to have no more than 1.5 GB, between RAM and swap. Often it's much less. With there being many reports of a single Firefox instance consuming over 700 MB after some fairly normal browsing sessions, a 1.5 GB limit is awfully close.

    There is no reason for any code to be contributed to any open source project that doesn't perform such basic checks. If they Mozilla developers really want to avoid having to manage memory manually, then perhaps it is time for them to transition away from C++, to a language that offers automated memory management. Say, Haskell or OCaml.

    1. Re:They're not "irrelevant bugs". by ergo98 · · Score: 1
      No, those are not "irrelevant bugs". They're examples of very sloppy coding

      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.

      With there being many reports of a single Firefox instance consuming over 700 MB after some fairly normal browsing sessions, a 1.5 GB limit is awfully close.

      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.

      There is no reason for any code to be contributed to any open source project that doesn't perform such basic checks.

      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.

      hen perhaps it is time for them to transition away from C++, to a language that offers automated memory management. Say, Haskell or OCaml.

      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.
    2. Re:They're not "irrelevant bugs". by Score+Whore · · Score: 0
      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.


      What a stupid thing to say. Applications don't have the capability to do proper memory handling in these circumstances. Your OS can look at the system and say "gosh, there's a good 900 meg sitting there unused, I'll use it for file cache" and then when an application comes along and requests some memory the OS easily dumps the cache to disk and give the app the memory. Firefox thinking "gosh, there's a good 900 meg sitting there unused, I'll use it for porn cache" is just stupid because there is absolutely no mechanism for the system to say "hey, that memory isn't *unused*."

      Any web browser developer who thinks that making "adaptive" use of gobs if memory is a good idea is a complete moron. Any kind of substantial RAM based web cache is just a bad fucking idea.
    3. Re:They're not "irrelevant bugs". by ergo98 · · Score: 2, Insightful
      What a stupid thing to say.

      And remarkably I said a simple statement of fact that said nothing about whether it was a good idea or not.

      Any web browser developer who thinks that making "adaptive" use of gobs if memory is a good idea is a complete moron. Any kind of substantial RAM based web cache is just a bad fucking idea.

      What an incredibly stupid thing to say.
    4. Re:They're not "irrelevant bugs". by Anonymous Coward · · Score: 0
      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.

      It's always dangerous to make assumptions in programming. I can think of plenty of situations where null pointer bugs have come to bite me in the ass in non-obvious ways. (Although since I do most of my development under Linux, and Linux overcommits memory, I've never actually had malloc() fail except under contrived conditions.)

      Here's an example: It's often convenient to use whether or not a pointer is null as a boolean flag, especially if the memory allocation is directly related to some state (such as "having a buffer already allocated"), thereby reducing potential inconsistencies.

      Now, let's say you're using a third party library. You pass your seemingly freshly-allocated memory to an API function. Trying to be helpful, it declines to operate on the null pointer. In fact, all the routines in the library are coded to ignore null pointers. At the end, you merrily "release" the memory, none the wiser. Or maybe you forget and just have a "virtual" memory leak.

      The effect of not having these operations performed is unpredictable, potentially catastrophic for data integrity, which is a bigger deal than simply crashing.

      Another example. Null pointers are often valid inputs to certain types of operations, such as containers. The presence or non-presence of a null pointer in, say, a symbol table may cause different behavior on the part of your application.

      For example, let's say you never normally store null pointers, and so can simply test whether some input is in the table, without separate testing if it's already null. Now, by accident, somewhere in the code, you put a null pointer in your table. Null pointer checks now succeed, and as a result, your code thiks nulls are valid inputs. This could have any number of effects.

      Even more insidious is if you start doing pointer arithmetic with a null pointer. Add a sufficient offset to the pointer, and it looks like a valid pointer. Now you've got a random buffer overflow, which is decidedly a BIG security issue.

      Basically, while all null pointer dereferences result in a crash (which isn't always so innocuous in itself, if it causes improper clean-up), not all null pointer operations are dereferences. Anything involving conditional testing is subject to issues, as is pointer arithmetic. Modern languages don't have the latter, but you've still got the issue of the former.
    5. Re:They're not "irrelevant bugs". by ergo98 · · Score: 1

      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.

    6. Re:They're not "irrelevant bugs". by Anonymous Coward · · Score: 0

      What you're failing to consider is that these sort of bugs are easily avoided. They're failing to do what amounts to a three or four line check, including the handling of the situation.

      An argument cannot be made regarding the cost of such checks, as they perform a very important function (ie. they prevent the program from crashing outright, possibly corrupting data), and they take but a few seconds of a developer's time to implement. Of course, the memory allocation functions of C can be wrapped, or the new operator of C++ overridden, to perform such checks and error handling automatically.

      So they write:
      char* str = (char*)malloc(sizeof(char)*length);

      When they should be writing:
      char* str = (char*)malloc(sizeof(char)*length);
      if(NULL == str) { /* Handle error. */
      }


      As you can see, it's not at all complex. It's really quite simple. As such, there are only two reasons for failing to do that check: ignorance and laziness.

      If a person fails to perform that check due to ignornace, then that person should not be a programmer. If that person is working for a firm, the firm should fire that person. If that person is volunteering for a project, the project should reject code and patches from that person.

      If the programmer is too lazy to perform such a basic check, then that person can be treated as being ignorant, and the application of the above policies would apply.

      Mozilla is one of the hallmark projects of the open source community. They can't afford to put out code with such simple, pointless mistakes. Not only does it make them look bad, but it puts a bad image on all the open source community. Beyond that, it makes people who suggest the use of Mozilla products look like fools. That's not a good way to gain widespread usage of your product, especially in the fact of fierce competition that do check the success of their memory allocation.

  59. A worrying issue raised... by Anonymous Coward · · Score: 0

    There's lots of "this is a good thing, now they can fix these bugs" posts but no one seems to have looked deeper into the matter. These bugs and issues have been found using a piece of software (although it's not clear how much expertise is needed to use the tool) and found a long list. Why has this only recently been done on a high profile project? How many month or even years have these issues been around? Almost certainly a number of these issues can lead to potential exploits. Even if it's only a tiny percentage, if you've a list that can be generated easily and is of large enough size then a potential malware author could just go through them one by one until he spots a vulnerability he could take advantage of. At the moment Firefox still isn't worth hackers time because of the size and nature of the userbase but if it ever becomes mainstream having so many problems identified with automated tools will just make hacker's jobs easier. Use of these tools need to become more widespread in Opensource projects, at some point it WILL be worth malware author's time to find an exploit they can take advantage of.

  60. Absolutely by psykocrime · · Score: 1

    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
  61. Firefox security and vulnerability by kc2keo · · Score: 1

    "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!

  62. What about library dependancies? by DigitAl56K · · Score: 2, Interesting

    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).

  63. Error severity is not the same by ovapositor · · Score: 1

    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!

  64. Having recently been through this... by rongage · · Score: 2, Insightful

    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
    1. Re:Having recently been through this... by zonx+lebaam · · Score: 1

      It's probably not enough of a big deal to spend lots of time on it, but you could always provide a controllerinterface_cleanup() routine of some sort that your user could (optionally) call during their exit processing. The cleanup routine could of course free walk down your datastructures freeing all the intentionally persistant malloc data (someday it might be useful for other processing as well). If the analysis programs still have some complaints, those complaints will have a higher chance of being valid. Plus, it might make you or your customers subjectively feel that the code is cleaner (different people's sense of style seems to vary dramatically).

    2. Re:Having recently been through this... by Anonymous Coward · · Score: 0

      You should optimise your library by pre-allocating big chunks of memory. Malloc works best in the general case (it's optimised for that), but it burns a lot of cpu cycles.

  65. new != malloc by Anonymous Coward · · Score: 1, Informative

    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.

    1. Re:new != malloc by ergo98 · · Score: 1

      new != malloc

      You're right. I was indeed being a little sloppy in my terminology, no doubt because little of my current development takes place in the C(*) ecosystem.

  66. Spinning Microsofties by tmh+-+The+Mad+Hacker · · Score: 1

    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?

    1. Re:Spinning Microsofties by YU+Nicks+NE+Way · · Score: 1

      They'd find next to nothing. The IE codebase has been run through low-sensititivity static analysis tools like this for years.

  67. I think that's a remarkable number... by TheDarkener · · Score: 1

    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.
  68. Well.... by Overfiend1976 · · Score: 1

    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.
  69. DUH?!? by x-vere · · Score: 1

    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.
  70. As someone who has used Klocwork before... by jonwil · · Score: 1

    ...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?

    1. Re:As someone who has used Klocwork before... by Doctor+Memory · · Score: 1

      Why can't you run Klocwork on your own code? Is it in a language Klocwork doesn't support?

      There are many static source analysis programs available for most of the popular languages (I've used them for both C and Java), was there some specific feature of Klocwork that you were looking for?

      --
      Just junk food for thought...
    2. Re:As someone who has used Klocwork before... by jonwil · · Score: 1

      I cant run Klocwork on my own code since I dont HAVE Klocwork.
      What I am looking for is a program that can do the things Klocwork can (detect possible memory leaks, buffer overflows and such) only without the big price tags.

      Is there a free (as in beer) solution for this?

    3. Re:As someone who has used Klocwork before... by Doctor+Memory · · Score: 1

      Yes

      --
      Just junk food for thought...
  71. Criticism... by big_dog_steve · · Score: 1

    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.

  72. Heh by MobileTatsu-NJG · · Score: 1

    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)

  73. Why wouldn't we want an analysis? by kinglink · · Score: 1

    "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)

  74. That's a GOOD thing by melted · · Score: 2, Insightful

    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).

  75. Another soul by paranode · · Score: 4, Funny

    Touched by His noodly appendage.

    1. Re:Another soul by Anonymous Coward · · Score: 0

      I always said God would be found in the source code.

  76. Watch by bendodge · · Score: 0

    Now, we see that there are many vulnerabilities in both IE and FireFox. Let's see what gets fixed faster.

    --
    The government can't save you.
  77. Re:Oh noez by dvice_null · · Score: 1

    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.

  78. It's still a better process than IE by Anonymous Coward · · Score: 0

    No one likes to have the project that they've put a lot of blood, sweat and tears into criticized, but this can only be for the best. That's what open source is all about, right? Anyone can look at the code, find bugs, and fix them (or tell the devs to fix them, in this case).

    Besides, I thought they already paid Coverity to do them a similar service, and Coverity found some real show-stoppers. Why isn't anyone in the OSS world developing the kind of software that Coverity is making such a boatload of money from?

  79. Moo by Chacham · · Score: 1

    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!

  80. False Positive Rate by Anonymous Coward · · Score: 0

    From what I've seen using Klocwork in the software development process, I would be surprised if more than a few turn out to actually be security issues. But, working through the analysis results should improve Firefox; so, it is a good thing.

  81. Bugs? by hpavc · · Score: 1

    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
  82. It's Time by Anonymous Coward · · Score: 0

    This is exactly what I've advocated for the 30+ years I've been an engineer. Spacecraft, mach-3 aircraft, probes, fundamental physics, all of it. We need code, we need open source code, we need independently verified code. This is a good thing.

  83. MOD PARENT DOWN by Anonymous Coward · · Score: 0

    Parent is wrong. Issues must be prioritized, and prioritization requires deciding if something is a minor issue or more important. If you have two issues where one is a single user's account being possible to destroy (not to gain access to the box, and not to destroy an arbitrary user's account, just a particular, specific user), and another bug where you can remotely perform arbitrary commands, as root, limited resources would be spent on the second one, first.

    To claim that all security related bugs are equal is ignorant at best, and disingenuous (sp?) at worst.

    Additionally, the particular requirements of an organization might make a particular bug minor. For example, if you can cause a printer to wait an extra second, once a day, before printing, you have a denial of service bug. Of course, this would be an insignificant DoS, as you can't effect anyone in any noticeable manner. But it's still a security issue, as it's still a DoS.

    Mod parent down. S/he doesn't know what s/he's talking about.

  84. if you have to know the code that well... by Albert+Sandberg · · Score: 1

    ..it might mean that in 682 possible places in the code, added/better documentation might be a good idea.

  85. Re:For one who works in QA this doesnt bother me.. by Anonymous Coward · · Score: 0

    "So this doesnt bother me" ... who cares if this doesn't bother you? The memory leaks alone are the absolutely ridiculous. These type of problems are more the cause of rapid development with minimal QA (that's your field right?) and testing. If they used test units or XP (not windows) or whatever methodology the development may have been slower but the software would be of significantly higher quality.

  86. And I, for one... by Anonymous Coward · · Score: 0

    ...welcome our new independantly reviewed overlords.

  87. So the heirarchy is: by jpellino · · Score: 1

    (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."
    1. Re:So the heirarchy is: by geekoid · · Score: 1

      All those are based on history with the product.

      MS has a history of dealing with these issues poorly, so it has a bad reputation to overcome.
      OSS has a good reputation in dealing with these issues.
      OSX doesn't have bugs, so the point is moot. ;) It's a joke.

      --
      The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    2. Re:So the heirarchy is: by WilliamSChips · · Score: 1
      OSX doesn't have bugs, so the point is moot.
      Of course, the reality distortion field turns them into features.
      --
      Please, for the good of Humanity, vote Obama.
  88. Well... SWEET Begina!!! by eno2001 · · Score: 2, Insightful

    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
  89. Do they welcome this? by pherthyl · · Score: 3, Interesting

    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/

  90. OMG NO WAI!!!! by pdpTrojan · · Score: 0, Funny

    This is clearly M$ FUD. Don't fall for it. Firefox is open source. It doesn't crash or have bugs.

  91. Re:For one who works in QA this doesnt bother me.. by Thrymm · · Score: 1

    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.

  92. Priceless... by Anonymous Coward · · Score: 0

    611 Defects
    71 Vulnerabilities
    1 Browser...

    The look on the face of a firefox fanboy: priceless.

  93. Automated Reporting has 'noise' in the errors also by sscottsci · · Score: 1

    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.

  94. Microsoft connection? by hisstory+student · · Score: 1

    The answer is yes but only if "Some folks at Klocwork" have no ties to Microsoft. Duh.

    --
    Heard any good sigs lately?
  95. The real question isn't... by Foolomon · · Score: 1
    The real question isn't whether they will address them. The real question is how will they address them.

    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?

  96. Memory allocation. by warrax_666 · · Score: 1
    The code doesn't check for null after a memory allocation? Isn't the C++ standard to throw an exception instead of returning null when an allocation fails?

    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.
  97. Only if... by Anonymous Coward · · Score: 0

    the analysis isn't sponsored by Microsoft or somehow implies that M$ software is superior...

  98. fud? by Vexorian · · Score: 1

    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"
  99. Don't they mean... by krkelly25 · · Score: 0

    ..."undocumented features"?

    --
    Talk without offending, listen without defending
  100. Excellent! by evil_Tak · · Score: 1

    This means that shortly, there will be 611 more bugfixes and 71 more potential security fixes!

  101. Doubt it by Almahtar · · Score: 1

    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.

  102. The Firefox team needs the help. by Futurepower(R) · · Score: 4, Interesting
    Firefox is the most unstable program in common use. Some of the most serious bugs, like the CPU hogging bug, are more than 4 years old. So it's great that the Firefox team is getting some help. They need it.

    (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:
    1. Maybe this bug is fixed in the nightly build.
    2. Yes, this bug exists, but other things are more important.
    3. No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated.]
    4. If you would just give us more information, we would fix this bug.
    5. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
    6. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
    7. I don't like the way you worded your bug report. [So, I didn't read it or think about it.]
    8. You should run a debugger and find what causes this problem yourself. [Then when you have done most of the work, tell us what causes the problem, and we may fix it.]
    9. Many bugs that are filed aren't important to 99.99% of the users.
    10. If you are saying bad things about Mozilla and Firefox, you must be trolling. [They say this even though Firefox and Mozilla instabili
    1. Re:The Firefox team needs the help. by bunratty · · Score: 1
      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.
      Then find the regression window so the problem can be fixed.
      --
      What a fool believes, he sees, no wise man has the power to reason away.
    2. Re:The Firefox team needs the help. by Anonymous Coward · · Score: 0

      22% hmmmmmm! My win 2000 laptop with latest firefox is hogging ..... 0% of cpu, so is it a problem with Firefox or a problem with WinXP??

      Now I wouldn't suggest that in one of the hundreds (ok tens) of WinXP patches there weren't something that looked for Firefox running and started up some cpu hogging busy-wait loop but Microsoft hasn't always played with a straight deck!!!

    3. Re:The Firefox team needs the help. by jkantola · · Score: 1

      > Firefox is the most unstable program in common use. Some of the most serious bugs, like the CPU hogging bug, > are more than 4 years old. So it's great that the Firefox team is getting some help. They need it.

      I've been running Firefox beta 2 since it was made available, and it seems to me that the
      cpu/memory hogging bugs have been fixed. At least the beta2 has been both more stable and
      less memory-hungry than just about any version since phoenix/firebird.

      Just my 2c...

    4. Re:The Firefox team needs the help. by syousef · · Score: 1

      Hmmm....I see lots of memory leaks but don't seem to see the CPU hogging...

      I agree there are problems with FF. I agree the team needs to address them and aren't doing so well at that at the moment. But I've used FF on a number of machines and not seen this particular problem (as opposed to memory leaks which I've seen on every machine) so I do wonder if there's something unique about your machine.

      --
      These posts express my own personal views, not those of my employer
    5. Re:The Firefox team needs the help. by permawired · · Score: 0

      I don't get it. I keep reading a number of people having issues with Firefox, but almost every issue that people complain about I have never seen or see on an extremely infrequent basis. Right now I'm writing this on version 1.0.6 which on all accounts should be extremely unstable. However looking at taskmanager, it is using 0-1% cpu (on a 3.2 Ghz P4 in HT mode) and about 87MB of ram. Now considering I have about 15 webpages open at this one time I'm not surprised of the mem usage. I activly use flash and view streaming video with it as well. The only time I've seen Firefox have issues is on one of the various dists of linux that I plop on my laptop. Some being worse than others. And it's not like I started using it last week, I've been running it for a few years now on various windows boxes with little to no issue.... I'm I just a really lucky bastard?

    6. Re:The Firefox team needs the help. by Anonymous Coward · · Score: 0

      "Your profile must be corrupt."

      How about fixing profile corruption?

              https://bugzilla.mozilla.org/show_bug.cgi?query_fo rmat=specific&order=relevance+desc&bug_status=__op en__&id=123929

      (Link to Bugzilla bug report)

    7. Re:The Firefox team needs the help. by Loopy · · Score: 1

      I don't see this CPU hogging. I do see the "memory leaks" if they are indeed leaks and not something else. (shows up on my XP SP2 boxes as the firefox.exe process continuously growing in memory size until after a week or so I have to close firefox, wait 'til the process exits and then relaunch it.)

    8. Re:The Firefox team needs the help. by Weedhopper · · Score: 1

      The CPU hogging is definitely real, at least on a Mac. I haven't seen it go past 40%, but if I have more than 10+ sites loaded on taps, I get slow memory hogging, usually plateauing around 20-25%. With all pages loaded.

      The only two extensions I'm using right now are TabMixPlus and NoScript.

  103. Just an observation. by Beefslaya · · Score: 1

    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.

  104. analysis by WeeBit · · Score: 1

    Internet Explorer analyze this!

  105. FireFox Copy & Paste Bug: Fixed!! by bunratty · · Score: 1
    --
    What a fool believes, he sees, no wise man has the power to reason away.
  106. My Thoughts by Anonymous Coward · · Score: 0

    "What are your thoughts do Firefox and the open source community welcome this kind of analysis?"

    My thoughts are these ubiquitous, lazy, and insincere tag lines prove Slashdot editors long ago stopped giving a rat's ass about the topics which comprise the content of this site. Typically not a word denoting knowledge or interest in the subject is spent. An automated attendant can spit out 'what do you think', 'what are your thoughts', 'everyone discuss', etc.

    Slashdot brought to you by Hallmark.

  107. Still... by CodemasterMM · · Score: 1

    Still, Firefox is more secure that IE6... I wonder how many holes are in that piece of swiss cheese software?

  108. Firefox Top 15 Excuses for Not Fixing Bugs by Futurepower(R) · · Score: 4, Insightful
    Firefox developers become "defensive" when so many users report problems? That's a new excuse for the collection:

    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:
    1. Maybe this bug is fixed in the nightly build.
    2. Yes, this bug exists, but other things are more important.
    3. No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated.]
    4. If you would just give us more information, we would fix this bug.
    5. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
    6. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
    7. I don't like the way you worded your bug report. [So, I didn't read it or think about it.]
    8. You should run a debugger and find what causes this problem yourself. [Then when you have done most of the work, tell us what causes the problem, and we may fix it.]
    9. Many bugs that are filed aren't important to 99.99% of the users.
    10. If you are saying bad things about Mozilla and Firefox, you must be trolling. [They say this even though Firefox and Mozilla instability is beginning to be reported in media such as Information Week. See the links to magazine articles in this Slashdot comment: Firefox is the most unstable program in common use.]
    11. Your problem is probably caused by using extensions. [These are extensions advertised on the Firefox and Mozilla web site, and recommended.]
    12. Your problem is probably caused by a corrupt profile.
    13. If you are technically knowledgeable, you can spend several hours trying to discover the problem: Standard diagnostic - Firefox. [Firefox has "Standard Diagnostics"! LOL.]
    14. I won't actually read the (many) bug reports, but I will give you some complicated technical speculation which pretends to be helpful but, on investigation, is shown to have nothing to do with the bugs.
    15. It's understandable that Firefox developers become defensive when users report so many problems.
    1. Re:Firefox Top 15 Excuses for Not Fixing Bugs by bunratty · · Score: 1
      15. # It's understandable that Firefox developers become defensive when users report so many problems.

      Where on earth did I say that?

      It should be:
      15. There is no specific information about the bug in the bug report.

      If you would stop with this general overall criticism and start reporting specific details of bugs so they can be reproduced and fixed, the problems you describe can be fixed. Until then, they cannot.

      --
      What a fool believes, he sees, no wise man has the power to reason away.
    2. Re:Firefox Top 15 Excuses for Not Fixing Bugs by Anonymous Coward · · Score: 0

      Thanks, but that is already #4 (as viewed from the other side).

    3. Re:Firefox Top 15 Excuses for Not Fixing Bugs by BenoitRen · · Score: 1
      Maybe this bug is fixed in the nightly build.
      It's a fact that bug reports rapidly get less useful the older your build is. You should test a recent nightly build first. Reporting a bug that's already fixed is a waste of time not only for you, but also for anyone looking at your bug.

      Yes, this bug exists, but other things are more important.
      This may be hard to understand for some users (I have trouble with it sometimes too), but there -really can be- more important things.

      No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated.]
      TalkBack is a separate program, how the hell can a crashed Firefox crash it? It's true that it doesn't always get called because Firefox has crashed so hard that it doesn't get to call the crash reporter, but this is not a common occurence.

      If you would just give us more information, we would fix this bug.
      This is true. If the given report is so cryptic and lacks the required details, the problem can't be located and it doesn't get fixed. It seems not everyone can understand this point, and thinks they have provided enough information.

      You should run a debugger and find what causes this problem yourself. [Then when you have done most of the work, tell us what causes the problem, and we may fix it.]
      This is open-source. The developers are not there to do your bidding. If they aren't interested in your problem or can't see it themselves, you go run a debugger to find the cause yourself.

      Your problem is probably caused by using extensions. [These are extensions advertised on the Firefox and Mozilla web site, and recommended.]
      I admit that this is a mess. Extensions are supposed to be these third-party pieces of code that the first-party developers aren't responsible for, so that's why they say this. But yeah, then Mozilla created an Add-Ons site and later started reviewing extensions, so the separation got muddled.

      Your problem is probably caused by a corrupt profile.
      This is a possibility, which is why you test the problem on a clean profile first, or make sure that the profile doesn't have anything to do with this.
    4. Re:Firefox Top 15 Excuses for Not Fixing Bugs by Anonymous Coward · · Score: 0

      It's interesting that there's a whole set of OSS excuses that aren't available to proprietary developers yet OSS is supposedly more responsive. With all the "eyeballs" that are supposed to be out there looking at OSS code, there should be hundreds of developers waiting with baited breath to run the debug session on behalf of the person who found a bug.

      Perhaps the reality is that the primary difference between proprietary and OSS developers is that the former has to take full responsiblity for their work and the latter can pass the buck.

    5. Re:Firefox Top 15 Excuses for Not Fixing Bugs by ebyrob · · Score: 2, Informative

      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.

    6. Re:Firefox Top 15 Excuses for Not Fixing Bugs by ebyrob · · Score: 2, Insightful

      Perhaps the reality is that the primary difference between proprietary and OSS developers is that the former has to take full responsiblity for their work and the latter can pass the buck.

      Na, buck-passing is an innate human trait. I don't think there's a software developer alive who hasn't done it. At least not an experienced one.

    7. Re:Firefox Top 15 Excuses for Not Fixing Bugs by Cid+Highwind · · Score: 1
      If you are saying bad things about Mozilla and Firefox, you must be trolling.

      Read this exchange and try to understand that sometimes it really is justified to dismiss a bug report as trolling. https://bugzilla.mozilla.org/show_bug.cgi?id=18222 1 (you'll have to cut and paste, bugzilla blocks links from slashdot)
      --
      0 1 - just my two bits
    8. Re:Firefox Top 15 Excuses for Not Fixing Bugs by Anonymous Coward · · Score: 0


              No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated.


      TalkBack is a separate program, how the hell can a crashed Firefox crash it? It's true that it doesn't always get called because Firefox has crashed so hard that it doesn't get to call the crash reporter, but this is not a common occurence.


      The code that launches TalkBack is not well hardened. If the bug that caused the problem is a heap corruption bug, the segfault handler that launches TalkBack is likely to segfault again, thus TalkBack never launches.

    9. Re:Firefox Top 15 Excuses for Not Fixing Bugs by arose · · Score: 1

      When was the last time developers of any mass market proprietary software have taken full responsibility of for their work?

      Greater user involvment in bug hunting is a core feature of OSS development, if you aren't ready to provide developers with information about the bug or test different versions of the software you should consider not reporting at all. Most FOSS projects don't have dedicated QA staff and a variety of hardware and software--reporting vague problems they can't reproduce and not providing specific information only wastes their time.

      --
      Analogies don't equal equalities, they are merely somewhat analogous.
    10. Re:Firefox Top 15 Excuses for Not Fixing Bugs by CTho9305 · · Score: 1

      You're a known troll, and I'm pretty sure I've replied to a very similar troll of yours before, but I'll bite for the benefit of anyone else reading this thread.

      1. Maybe this bug is fixed in the nightly build.
      That's because dozens of bugs are fixed every day and there are usually a lot of days of development between the released version and the latest nightly builds at the time someone reports a bug. If it's not trivial to reproduce, it's not a good use of the developer's time, since hundreds of bug reports are filed daily. If each reporter takes 5 mintes to try a nightly build, the average per-user time is going to be 5 extra minutes. If developers have to try convoluted steps to reproduce per bug, it's going to be hours of wasted time per developer.... even if the steps to reprdoce are simple, if the developer doesn't experience the bug in a nightly build, it's a valid question. The bug is either fixed in that nightly build, or other factors make it a works-for-me for the developer (for example, a changed preference setting). The only way to tell the two apart is to ask the user to test in a newer build.

      2. Yes, this bug exists, but other things are more important.
      What, you think that just because an icon that's off by one pixel somewhere bothers you a lot, they should fix that before they fix actual functionality issues, or accessibility issues, or crashes, or add new features that will benefit hundreds of thousands of users? What kind of stupid complaint is this? Everybody intelligent prioritizes tasks.

      3. No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated.]
      I've DEFINITELY responded to this before.

      4. If you would just give us more information, we would fix this bug.
      I've responded to this too. I guess you just drop this list on any bug that mentions Mozilla. Anyhow, as I would have said before, do you think developers are clairvoyant? If you file a bug that says, "The URL bar is broken", what do you expect? If the developers don't have enough information to reproduce your bug, or can't reproduce it themselves, well, they need more information.

      5. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
      I'm not going to point out further comments I've addressed before. This is a legitimate reason a bug is invalid. However, it is fair to complain that whoever closed the bug did not specify the bug #s. Do it in the bugs, not on slashdot, because it will be seen if it's in the bug report. Complain on IRC if it's specific people doing it.

      6. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
      I don't recall seeing anyone say that. Where you deleting random files in the Firefox directory or something?

      7. I don't like the way you worded your bug report. [So, I didn't read it or think about it.]
      I don't recall seeing anyone say that. However, if your bug report is unreadable, it makes sense for the developer to move on to something he/she can actually understand...while at the same time letting the reporter know that he/she needs to write clearly for the problem to be understood so it can get addressed.

      8. You should run a debugger and find what causes this problem yourself. [Then when you have done most of the work, tell us what causes the problem, and we may fix it.]
      Well, if no developers can reproduce it and the symptoms/steps to reproduce don't make it apparent where the problem lies, they can't do anything unless someone who can reproduce it does use debugging

  109. Not bad going by dustrider · · Score: 1

    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."

    1. Re:Not bad going by cmndr_nick · · Score: 1

      In fact, Klocwork provided Mozilla with full supporting defect info - including: full details of the analysis - including line #s of all defects. We also provided them with access to the Klocwork tools that allow them to manage the defects (indicate that they are defects, not defects, fix now, fix later, etc.) We have hosted the results of the analysis on our system, so that when we analyze the next build, we can do comparative analysis between builds to show new defects that have been added, and which defects were taken care of. This is provided on a complimentary basis to non-commercial open source vendors. Results of all of these projects are posted here: http://www.g2zero.com/open_source_analysis/ By definition, open source software is the repsonsibility of the entire software community. It is too bad that people use this as an opportunity to beat up Firefox/open source. This should not be interpreted to say that other commercial software vendors produce software with higher quality and fewer defects, etc. Nick - Klocwork

    2. Re:Not bad going by dustrider · · Score: 1

      Just goes to prove: "A good tester is worth his weight in gold." Sorry to have implied that you'd do otherwise. Good job.

  110. yes, as long as.... by cliffwoolley · · Score: 2, Insightful

    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.

  111. The "Standard Diagnostic". by Grendel+Drago · · Score: 1

    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
    1. Re:The "Standard Diagnostic". by Anonymous Coward · · Score: 0

      The change was inevitible. In those "halcyon" days the comparison was a legacy free Linux vs. legacy-laden Windows 3.0/3.195/98/ME. Then Windows NT family came along and the stablity argument became more difficult to make (although people still like to compare Linux with pre-NT versions of Linux).

  112. bleach & onion patches by foQ · · Score: 1

    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?

  113. That oo.org bug is horrifying. by Grendel+Drago · · Score: 4, Insightful

    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
    1. Re:That oo.org bug is horrifying. by Shaper_pmp · · Score: 1

      Amen. Or my favourite example.

      I love open source, and would dearly love to help the developers by submitting detailed, accurate, complete bug reports[1], but fly-by-night dillettante trivialising attitudes like this make me want to pack the whole thing in and turn back to a Microsoft-only existence. MS crapware may be buggy as hell, but at least they don't pretend they're interested in bug reports only to get the hairy arsehole when you try to submit one.

      [1] I'm a developer too, just one without the free time to spend hacking OSS code.

      --
      Everything in moderation, including moderation itself
  114. Of course they do by DrXym · · Score: 1

    Why wouldn't they want to know about potentially up to 71 vulnerabilities plus numerous other bits of code to cleanup?

  115. Opera easily countable using useragent string by Chuck+Chunder · · Score: 4, Informative

    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
  116. Of cource! by zerosix · · Score: 1

    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
  117. Motivations Redux... by ElboRuum · · Score: 1

    What's the motivation to fix it in an Open Source environment? Altruistic tendencies?

  118. Welcome this kind of analysis by aCapitalist · · Score: 3, Insightful

    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"?

  119. It isn't Open vs Proprietary that is significant h by mikefocke · · Score: 1

    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.

  120. It's sorta like... by E++99 · · Score: 1

    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."

  121. Yeah, but how many people on /. are FF developers? by Anonymous Coward · · Score: 0

    I doubt many, if any, here on /. have ever contributed to Firefox code. There seems to be many critics of closed-source apps on here, but not actual Firefox developers.

  122. Yes. by bradtes · · Score: 1

    Do Firefox and the open source community welcome this kind of analysis?

    Yes, you silly wanker.

  123. Never Fear Window Snyder is here :D by DaveRexel · · Score: 1

    "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."

    http://it.slashdot.org/article.pl?sid=06/09/06/214 7254

    --
    # ~: no sigs today
  124. Try a new profile by bunratty · · Score: 3, Informative
    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?

    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.
    1. Re:Try a new profile by Denny · · Score: 1

      I filed a bug against Mozilla once, an obscure CSS layout glitch. The original bug report was very hand-wavey, I didn't really know what I was trying to report, just that it didn't seem to be doing the right thing. The developers were extremely helpful in the bugzilla comments, and guided me through the process of refining my bug report and giving them enough information to find out what the problem was and work out whose responsibility it was and how important it was. It was fixed two releases later. I was very very impressed by the whole process.

      --
      Police State UK - news and
  125. Re:For one who works in QA this doesnt bother me.. by Anonymous Coward · · Score: 0

    "The memory leaks alone are the absolutely ridiculous."

    I've used Klocwork for analysis; in my experience, when K7 identifies a memory leak at location foo, it is correct less than 5% of the time. So, I would be quite surprised if even 10 of the 141 items flagged are actually memory leaks.

  126. SessionSaver by bunratty · · Score: 1
    ...no matter how many tabs I've got open via seesionsaver...
    Then don't use SessionSaver, because it has known memory leaks.
    --
    What a fool believes, he sees, no wise man has the power to reason away.
  127. Welcome???? Why not? by Anonymous Coward · · Score: 0

    I fail to see the problem - If you are working on an open source project and someone steps in and tells you about problems you are not going to tell people to make like a tree.... or tell them to mind their own business - Au contraire you are going to welcome such a thorough analysis because it gives you the opportunity to better your software...

  128. What's Really Significant Here by CyberLife · · Score: 1

    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.

  129. Low-memory browsers by bunratty · · Score: 1

    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.
  130. Im woried by POds · · Score: 1

    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/
  131. Version? by tonyr1988 · · Score: 1
    The Firefox team has been given the analysis results, and they will determine if or how they will deal with the issues.
    It says they were done on v1.5.0.6

    I'm running 2.0b2 right now. I wonder how many of them have already been fixed?
  132. AET IT! AET IT! by Ayanami+Rei · · Score: 1

    cp == b&

    --
    THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
  133. You're a fool, Dennis Forbes. by Anonymous Coward · · Score: 0

    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 obviously have no experience with real-world software. A segfault caused by something as stupid as not checking the success of a memory allocation can be disasterous. Let's even just restrict ourselves to consumer/corporate-grade software. If that were to happen within a production web server, millions of dollars in sales could be lost. If that were to happen within a database system, the data loss could be very costly. If your browser were to crash while you were in the middle of performing an online banking transfer of several thousand dollars, it could lead to serious problems for you. And the worst part about such problems is that they're so easily detected!

    And yes, dealing with a failed memory allocation can be complex. Software is often very complex. Professional developers know that, and successfully deal with it. Only an amateur would take your attitude of, "It's difficult to deal with, so I'll just ignore it if it happens, not caring what the result may be."

    Many languages offering garbage collection do run into problems when all of the memory is consumed. Those that do happen to throw exceptions do so in a way that makes it very clear what the problem is, and why it occurred. Most of those that are suitable for production use don't just dump core. They alert a system operator to the lack of memory, and the operator can remedy the problem (if possible), and then allow for the execution to continue from where it left off.

    That is not the case when a failed call to malloc() leads to a segfault, and you as the developer don't bother to check the return value. Unless you have a debugger, and a binary with debugging symbols and/or the source code of the application, you basically have no idea what happened. And if it were a failed allocation due to all the memory being consumed, it can be a most difficult problem to replicate. It might work fine on the developer's system with 1 GB of RAM and 2 GB of swap, but fail every time on your system with only 512 MB of RAM.

    At least checking for the condition allows one to output an error message, even if it is handled by an immediate termination of the process. Your attitude of it being acceptable to not even check the return value is sickening. I hope that you are not allowed to perform any programming tasks, as you obviously lack the skills necessary to develop software in a safe, secure manner. Your lack of basic C programming technique is pathetic.

    1. Re:You're a fool, Dennis Forbes. by ergo98 · · Score: 2, Insightful
      You obviously have no experience with real-world software.

      Way more than you.

      A segfault caused by something as stupid as not checking the success of a memory allocation can be disasterous.

      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.

      They alert a system operator to the lack of memory, and the operator can remedy the problem (if possible), and then allow for the execution to continue from where it left off.

      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.

      blah blah blah...blah blah blah...blah blah blah

      Maybe you should meet up with the real world some day.

      I hope that you are not allowed to perform any programming tasks, as you obviously lack the skills necessary to develop software in a safe, secure manner.

      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!
  134. Does it take a tool to highlight bugs by rhubarb42 · · Score: 1

    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.

  135. well... by oohshiny · · Score: 1

    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.

  136. Most are glaring bugs that aren't being fixed.... by spinctrl · · Score: 2, Insightful

    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).

  137. Re:Yeah, but how many people on /. are FF develope by dveditz · · Score: 1

    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.

  138. Re:WHICH Firefox? by aichpvee · · Score: 0, Offtopic

    That's actually a good idea. How about they add a Linux Firefox or KDE Firefox while they're at it? I'm sick of having to use GNOME Firefox because it's the only one available.

    --
    The Farewell Tour II
  139. SO ARE YOU ANONYMOUS COWARD by ergo98 · · Score: 1

    ...And reading my name FROM THE EMAIL LISTED ABOVE is pure super techno fu. You must be some sort of elite hacker!

  140. Ass, U, Me by tcgroat · · Score: 1

    "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!

  141. No offence... by tickticker · · Score: 1

    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

  142. Re:Oh noez by ClosedSource · · Score: 1

    "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.

  143. Mod parent down a bit by Ernesto+Alvarez · · Score: 1

    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)

  144. gb2/b/ by Knnniggit · · Score: 1

    nt

    --
    Brain kills internet cells.
  145. time to look for another by Anonymous Coward · · Score: 0

    i think now its a time to look for another browser :)
    http://www.secgeeks.com/

  146. Re: 611 Defects... by c0sine · · Score: 1

    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
  147. okey, that's pretty low number of holes by AnXa · · Score: 1

    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-
  148. Firefox CPU hogging interacts with Thunderbird. by Futurepower(R) · · Score: 1

    "... 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.

  149. You didn't read the bug report. (No offense taken. by Futurepower(R) · · Score: 1

    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.

  150. NEW! Firefox Top 20 Excuses for Not Fixing Bugs. by Futurepower(R) · · Score: 1
    You made some good points, so here is an updated list.

    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.
    1. Maybe this bug is fixed in the nightly build. [The same bug has been reported many, many times over a period of four years.]
    2. Yes, this bug exists, but other things are more important. [The bug eventually takes 100% of CPU power, and makes Windows XP unusable, even after Firefox is killed. The bug affects the heaviest users of Firefox.]
    3. Yes, this bug exists, but it is not a common occurrence. [Numerous users have reported the bug. See the links.]
    4. Works for me. [The bug is complicated to reproduce, so the developers did a simplified test, which didn't show the bug.]
    5. No one has posted a TalkBack report. [If they had read the bug report, they would know that there is never a TalkBack report, because the bug crashes TalkBack, too, or a TalkBack report is not generated. TalkBack does not generate a report if Firefox is hogging the CPU. TalkBack cannot generate a report if the bug takes 100% of the CPU time.]
    6. If you would just give us more information, we would fix this bug. [They didn't bother to reproduce the bug using the detailed information provided.]
    7. This bug report is a composite of other bugs, so this bug report is invalid. [The other bugs aren't specified.]
    8. You are using Firefox in a way that would crash any software. [But the same use does not crash any version of Opera.]
    9. I don't like the way you worded your bug report. [So, he didn't read it or think about it.]
    10. You should run a debugger and find what causes this problem yourself. [Then when you have done most of the work, tell us what causes the problem, and we may fix it.]
    11. Many bugs that are filed aren't important to 99.99% of the users.
    12. If you are saying bad things about Mozilla and Firefox, you must be trolling. [They say this even though Firefox and Mozilla instability is beginning to be reported in media such as Information Week. See the links to magazine articles in this Slashdot comment: Fire
  151. Volunteer QA people can close bugs, too by bunratty · · Score: 1

    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.
  152. Re:NEW! Firefox Top 20 Excuses for Not Fixing Bugs by bunratty · · Score: 1
    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.

    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.
  153. Re:Insensitive clod! by LWATCDR · · Score: 1

    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.
  154. Re:NEW! Firefox Top 20 Excuses for Not Fixing Bugs by revengance · · Score: 1

    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.

  155. Blarg. FF sux anyways by Anonymous Coward · · Score: 0

    I don't get the big deal with FF. Its an underpowered, WAAAAAY over hyped peice of software that really doesn't have much going for it other than it being open Source. And last time I checked, I didn't exactly feel like mucking through ugly web browser code. In my opinion Firefox is way hyped up and is not really 10% as good as people will try to Jedi mind Trick you into beleiving. Me, I switched to a great web browser long ago (hint hint: Opera), back when Mozilla.org abandoned Mozilla suite.
    That being said, finding xxx amount of flaws and security problems in an ALREADY way over-hyped browser really doesn't do much in terms of winning me over. In short, I couldn't care less if Firefox has 3 x as much flaws and secirty problems! I also highly advise people not to buy the pre-packaged and manufactured firefox hype, and to try Opera. But no one ever listens.

    over and out.

  156. The most common types of vulnerability by Ed+Avis · · Score: 1
    Finding and fixing an individual vulnerability is necessary, but not that interesting. What's more important is to look at what kind of bug it is, see if it occurs elsewhere, and see what might be done to stop it happening in future. Often that means providing programmers with a safer mechanism that makes it harder to introduce bugs (or makes bugs that do creep in be harder to exploit). The OpenBSD project has justly become famous for this kind of auditing, for example, they found in auditing that copying of C-style strings often led to exploitable buffer overruns, and developed strlcpy() as a safer alternative.

    So what does the Firefox list tell us?

    A large number of defects resulted from the code not checking for null after memory was allocated.
    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.

    In addition, there were many cases where the return value of functions designed to return null were not checked prior to dereferencing.
    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:

    With most of these tools the signal:noise ratio is very high. For example, most of these "dereferencing null" cases are either handled automatically by C++ template wrappers that do smart pointer management. Many of these "potential" memory leaks are handled automatically by XPCOM's refcounting.
    So it looks like the Mozilla folk have already thought about these problems and done the Right Thing.
    --
    -- Ed Avis ed@membled.com
  157. Re:NEW! Firefox Top 20 Excuses for Not Fixing Bugs by Apoklypse · · Score: 1

    hey, yeah there's good ol' microcrap lowering that common denominator for ya ...

  158. You're still a fool, Dennis Forbes. by Anonymous Coward · · Score: 0

    What are we talking about again? Oh, right, a fucking web browser.

    Actually, we are just talking about normal web browsers here. The rest of us, we do not perform sexual intercourse with our web browsers. We don't "fuck" our web browsers, as you claim to do. But many people do use their web browser to perform vital financial transactions online. A $1000 transfer may not seem like much in the grand scheme, but if a browser crash causes that transaction to fail, or otherwise become lost, the person performing the transfer will likey become quite irrate. Web browser stability is very essential.

    Since you seem to be so sure of yourself and your programming abilities, I want you to post your full name, your current employer, your position with that employer, and a list of software products you have worked on. Do that for all of your past employers, and any projects you worked on at those places. I want to make sure that my firm never buys anything that you have worked on. From this discussion, you would appear to be an incompetent software developer who has little to no background writing secure, reliable systems. I don't want your software anywhere near my network.