User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4) Gecko/20091007 Firefox/3.5.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.4) Gecko/20091007 Firefox/3.5.4 SSL does not work, and you get a "Could not initialize the application's security component" message on startup if you upgrade from 3.5.3 to 3.5.4 with FIPS mode enabled. Reproducible: Always Steps to Reproduce: 1. Install Firefox 3.5.3 2. Set a Master Password 3. Enable FIPS mode 4. Upgrade to Firefox 3.5.4 candidate. Actual Results: Error message appears on startup: "Could not initialize the application's security component. The most likely cause is problems with files in your application's profile directory. Please check that this directory has no read/write restrictions and your hard disk is not full or close to full. It is recommended that you exit the application and fix the problem. If you continue to use this session, you might see incorrect application behaviour when accessing security features." SSL connections result in an error page (Error code: ssl_error_ssl_disabled) Expected Results: Firefox starts up normally, SSL connections work after entering the master password. I was able to workaround the issue by downgrading to 3.5.3, disabling FIPS and the master password, then upgrading, then re-enabling a master password. I couldn't get FIPS enabled in 3.5.4: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPKCS11ModuleDB.toggleFIPSMode]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://pippki/content/device_manager.js :: toggleFIPS :: line 545" data: no] A second attempt resulted in a delayed crash (http://crash-stats.mozilla.com/report/index/18a0ef70-ad24-4e80-8096-d28d32091012) In the broken 3.5.4 profile with FIPS enabled, there were duplicate NSS/PSM entries in Security Devices.

I can confirm this problem on WinXP after updating from 3.5.3 to 3.5.4 on the beta channel (didn't try the workaround). In the Firefox preferences the "Use a master password" box is not set, and there is an "Enable FIPS" button in the Security Device Manager; you get an "Unable to set Master password" message if you try to set one. A fresh profile with 3.5.4 allows you to set a master password but not enable FIPS - the error console has the toogleFIPSMode exception from above. I've verified that all three chk files - freebl3.chk, nssdbm3.chk, softokn3.chk - are present in the installer, but I don't recall how to verify they're valid.

This seems quite similar to Bug 503418.

Bug 520063 may have been the same thing, with the Thunderbird nightly from either 2009-10-01 or 2009-09-30.

(In reply to comment #1) > I can confirm this problem on WinXP after updating from 3.5.3 to 3.5.4 on the > beta channel (didn't try the workaround). In the Firefox preferences the "Use a > master password" box is not set, and there is an "Enable FIPS" button in the > Security Device Manager; you get an "Unable to set Master password" message if > you try to set one. > > Also confirmed the workaround, enabling the FIPS Mode in 3.5.4 does not work even when you had FIPS disabled (not selected) before the update. Seems to be a regression.

We would need a regression range. Possible related bugs which have been fixed for 3.5.4 especially for FIPS mode: bug 509558, bug 509319.

Is this only on 1.9.1? Is 1.9.2 or trunk affected?

(In reply to comment #6) > Is this only on 1.9.1? Is 1.9.2 or trunk affected? i see the same in Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.3a1pre) Gecko/20091011 Minefield/3.7a1pre Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPKCS11ModuleDB.toggleFIPSMode]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://pippki/content/device_manager.js :: toggleFIPS :: line 545" data: no]

I will start with a regression test now.

If you open such a profile with a build on 1.9.2 or trunk the browser will crash immediately. See bug 522041.

Regressed between the builds 09091603 and 09091703: Pass: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b7dd9891657f Fail: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f3f8aeecc2bd Changesets: http://hg.mozilla.org/releases/mozilla-1.9.1/pushloghtml?fromchange=b7dd9891657f&tochange=f3f8aeecc2bd Definitely a regression from bug 509319 as already thought in comment 5. So I believe bug 522041 is the same fallout but crashes on 1.9.2 and trunk.

We're going to respin Firefox 3.5.4 builds for this issue.

While there may well be other FIPS bugs on other platforms and branches, I'd expect that _this_ is Windows/1.9.1 only - if you look at the Firefox3.5 tinderbox logs, you'll see that on Linux and OS X, signing of nssdb3 goes just fine, but on Windows it appears to silently crap out somewhere (in a path through the program that I can't spot), so that you don't get the "moduleSpec..." or "Generate a DSA key pair ..." lines that you get on non-Windows, and on Windows for the other two dlls being signed, but still manage to make it down to the "Library File:..." and following lines.

Looks OK to me, what am I missing Phil ?

Gah, we Authenticode signed nssdbm3.dll and therefore invalidated nssdbm3.chk. We don't signed freebl3.chk or softokn3.dll for this reason.

This should do the trick, I'll go verify that.

What you were missing is that we were talking about two different signings: yours is from http://mxr.mozilla.org/mozilla1.9.1/source/security/nss/cmd/shlibsign/Makefile#118 while building NSS, mine is from http://mxr.mozilla.org/mozilla1.9.1/source/toolkit/mozapps/installer/packager.mk#233 while making package|installer.

And it can't (just) be Authenticode signing, can it? We don't sign nightlies or hourlies, which I assume were the source of Henrik's range, and Bob Lord's probable dupe bug 520063.

This also looks OK. Could the -j4 of nightlies be mixing up the logs a lot ? What I've got here is already a mixture of stdout and stderr, and buildbot sometimes gets the ordering a little wrong. Otherwise I don't understand that. make installer doesn't regenerate the chk files as far as I can see.

Comment on attachment 406103 [details] [diff] [review] Add nssdbm3.dll to signing exception list I re-signed an en-US and de installer for 3.5.4 build1 using this patch, and was able to enable FIPS mode and visit https sites. Also confirmed that linux and mac are not affected. Don't know what to make of Tomcat's comment #7.

We may be fine for 3.0.15, where we're using NSS 3.12.3. We sign nssdbm3.dll but we're not packaging a chk file (which became a requirement in 3.12.4 IIRC) so that's OK. Good even, since we should sign every binary we can except where restricted. FIPS behaves slightly weirdly though: When you press "Enable FIPS" the button label changes to "Disable FIPS" but the button is disabled. You can still visit https sites and there's no error in the console. If you restart Firefox then the button is re-enabled. Same thing if you then go "Disable FIPS"

Nick, OS X is definitely affected. My regression tests are based on nighly builds on OS X. So I wonder if we should file a new bug for OS X (and Linux)?

Ok, I did the tests again and now I'm crashing too with Shiretoko. Looks like the OS X part is bug 522041.

Comment on attachment 406103 [details] [diff] [review] Add nssdbm3.dll to signing exception list Is release/signing/signing.py in any MXR search? When I worked on the nssdbm3.chk issue, I searched mozilla-central for "softokn" to make sure I changed every file that needed changing. But release/signing/signing.py isn't in http://mxr.mozilla.org/mozilla-central/. What is a Mozilla developer to do? So now I know I also need to search in http://mxr.mozilla.org/build/. Anything else?

Comment on attachment 406103 [details] [diff] [review] Add nssdbm3.dll to signing exception list http://hg.mozilla.org/build/tools/rev/115349b92de8

To avoid this in future we should fix bug 489961 in a way that * signs freebl3.dll etc rather than excepting them * regenerates all chk files present in unsigned build * puts the regenerated chk files in the complete mar to also fix bug 404340

(In reply to comment #20) > FIPS behaves slightly weirdly though: When you press "Enable FIPS" the button > label changes to "Disable FIPS" but the button is disabled. You can still visit > https sites and there's no error in the console. If you restart Firefox then > the button is re-enabled. Same thing if you then go "Disable FIPS" ss: dveditz: is this expected behavior, or should we spin this out into a separate bug?

John: that's expected behavior. The button is disabled after you press it to prevent you from toggle it again in the same browsing session. I forgot the reason why NSS doesn't allow you to toggle the FIPS mode twice.

(In reply to comment #23) > So now I know I also need to search in http://mxr.mozilla.org/build/. > Anything else? Can't think of anywhere else we stash signing scripts (that we still use).

(In reply to comment #25) Nick Thomas wrote: > To avoid this in future we should fix bug 489961 in a way that > * signs freebl3.dll etc rather than excepting them > * regenerates all chk files present in unsigned build > * puts the regenerated chk files in the complete mar to also fix bug 404340 Hear! Hear! I asked Dan Veditz why those steps aren't already happening. As I understood (or perhaps misunderstood) the response, it was due the the belief that regenerating the .chk files meant moving the signed .DLLs from the special system where they are authenticode signed back to the system (and build tree) where they were built, and then re-running part of the make that built them, the part that runs shlibsign to generate the .chk files. This is deemed awkward, perhaps labor intensive, potentially error prone, and generally ugly from an automated release generation perspective. But I have good news (No, I didn't switch to GEICO :). Unlike the authenticode signing process, which requires a secret key that must be carefully protected, and is generally restricted to just one system for that reason, the process of generating the .chk files can be done on any windows system. It need not be the system on which the build was orignally done, and it need not be done with the very same copy of shlibsign that was built along with the DLLs being "signed" by shlibsign. Yes, we've integrated the use of shlibsign into the NSS build, but that's not essential. You can run shlibsign whenever you like. In essence, you can regard shlibsign as just another tool, like another compiler or post processor of some kind. You can build it once, and keep that one built copy and use it over and over for days, weeks, months, years on end. shlibsign itself hasn't changed in a long time. You could use a copy built (say) a year ago and it would work just fine today. You could put a copy of shlibsign on the authenticode signing system (if that appeals to you), and then just run it for each .DLL file whose .chk file needs to be regenerated, after that DLL has been authenticode signed. Or, if there's some other system on which you do packaging after you do the authenticode signing, and you would rather do the .chk file regeneration there, just put the shlibsign program (and the DLLs it needs) there, and use it there. I hope this helps.

Nelson, that's very much what I had in mind, but lets have that discussion in bug 489961.

Verified fixed with 3.5.4 build2: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4) Gecko/20091014 Firefox/3.5.4 (.NET CLR 3.5.30729) ID:20091014223740