Although the interminable feeling the author had while waiting for Firefox 3.5 to start up mirrored my own feeling of waiting for him to get to the f'ing point, he's absolutely right: Firefox should just be using the system's secure random number generator on each platform. If you have a vulnerability in /dev/random or CryptGenRandom(), you have a massively more important finding than Firefox crypto.
To summarize for those who have less spare time than I:<p>Some firefox developer had a Very Bad (tm) idea to seed a random number generator by scanning the Windows Temp folders, which is now causing a 30 secs to over a minute pause in start up for a lot of users (particularly those that use IE, which creates a LOT of temp files). Yikes.
If you want to see the code that does this:<p>EnumSystemFiles: <a href="http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/freebl/win_rand.c#182" rel="nofollow">http://mxr.mozilla.org/mozilla-central/source/security/nss/l...</a><p>...called by rng_systemJitter: <a href="http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/freebl/win_rand.c#359" rel="nofollow">http://mxr.mozilla.org/mozilla-central/source/security/nss/l...</a><p>...called by rng_systemFromNoise: <a href="http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/freebl/sysrand.c#74" rel="nofollow">http://mxr.mozilla.org/mozilla-central/source/security/nss/l...</a><p>...called by RNG_SystemRNG: <a href="http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/freebl/win_rand.c#509" rel="nofollow">http://mxr.mozilla.org/mozilla-central/source/security/nss/l...</a><p>...called by (among others) rng_init: <a href="http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/freebl/drbg.c#379" rel="nofollow">http://mxr.mozilla.org/mozilla-central/source/security/nss/l...</a>
Maybe it's just me, but I consider this a (serious) security issue as well. The contents of temp files, which Firefox shouldn't even have access to, will now float around in the process memory of Firefox, even after the memory has been deallocated.<p>Firefox should never, ever, ever, open any file outside its own app directory, user preferences directory, or cache directory.<p>And a reasonably secure OS shouldn't even allow Firefox to open any of those files.
One bug is a "fiasco"? How about the 15 years the web has been set back by supporting broken browsers like IE6? Oh, well at least it starts up quickly...<p>The real issue here is how hard it is to be a consumer of open source software on Windows. On Debian, if I wanted to fix this, I would just "apt-get source" the relevant package, make the change, and have Debian build me a new package with the fix. On Windows, this is apparently not possible, as there is no package management system to install the compiler and source code for you, and the apps check themselves to make sure that you don't modify them.<p>(I also like how the virus / spyware situation is so out of hand on Windows that you can't even recompile libraries without your own computer assuming you are hacking yourself. Nice.)<p>Why do people still use Windows?
It gets worse security-wise -- their recommended fix is to delete all your caches, removing the entropy seed from their RNG: <a href="https://support.mozilla.com/tiki-view_forum_thread.php?comments_parentId=381674&forumId=1" rel="nofollow">https://support.mozilla.com/tiki-view_forum_thread.php?comme...</a><p>And if clearing the caches doesn't affect entropy quality, it's even stupider -- why bother to read them in the first place?
Well yes, it's a bug but it's hardly a fiasco. Something like this should be caught in pre-release testing. Still, most users have their browsers running all the time anyway so a slow startup is not really that critical.
I've seen far more serious bugs being taken far more lightly.
I wish the Firefox developers would focus on bug fixing for the next big release. There are so many bugs that are not fixed for many years. For example alt-text on images not correctly shown or disable-output-encoding on XML/XSLT being ignored. Instead that add more and more features. The awesome bar already made me switch to Opera, I miss some extensions though so I do keep an eye if Firefox gets "better" for me.
And this is precisely why the most recent Firefox install I have is from the 2.x series. It used to be that Firefox (then Firebird) was the lean and mean cousin of bloated Netscape. Alas, age has taken it's toll and the amount of built in crud in Firefox that has nothing to do with downloading had display HTML documents is overwhelming...
The "thread dump" feature should be an absolute requirement for any language runtime environment. Java has perfected this with the SIGQUIT signal. Thread dumps give you readable stacks of all threads with a simple user command (kill -3 on Linux/Unix, although a bit more difficult on Windows), without having to install symbol files, install additional software, run "scary" commands (for end users), etc.<p>This is a textbook example of taking a few thread dumps, a few minutes apart, immediately showing what is going on. IBM has one of these as their Performance or Hang "MustGather" script:<p><a href="http://www-01.ibm.com/support/docview.wss?uid=swg21115785&aid=4" rel="nofollow">http://www-01.ibm.com/support/docview.wss?uid=swg21115785...</a><p>.NET thread dumps suck -- you have to use adplus to attach and they're not easy to read. Native programs (e.g. C/C++) work better with symbols and are just too scary for end users. DTrace on Solaris with Ruby/Python/PHP extensions is nice, but too cumbersome to install, and again too scary for end users.<p>I'm not aware of built-in thread dumps-by-signal in other non-Java languages (please note in a comment if there is), but this feature is so basic and needs to be baked in to every runtime environment and easy enough for end users to use.<p>Firefox, being a native program, is in a bad problem determination position here and the haphazard nature of the problem determination process in the forum and bug report shows that. I suggest Firefox create something like IBM's MustGather scripts (starting with a performance one such as IBM's hang MustGather -- <a href="http://www-01.ibm.com/support/docview.wss?uid=swg21115785" rel="nofollow">http://www-01.ibm.com/support/docview.wss?uid=swg21115785</a> [click "Show Details" for the steps]). A hang MustGather should go through the process of installing symbol files, getting the thread stacks, submitting the information, etc. This will allow users to at least feel like they can do something valuable to help the developers fix the problem.
FYI Mozilla does have an open blocker bug about this problem:<p><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=501605" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=501605</a>