Closed Bug 262822 Opened 19 years ago Closed 19 years ago
FIPS can't be enabled
1.11 KB, patch
|Details | Diff | Splinter Review|
6.25 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 In Preferences -> Privacy & Security -> Certificates -> Manage Security Devices selecting the "Enable FIPS" button doesn't work. This is a SuSE Linux 9.1 system. On Windows 2000 Prof after selecting "Enable FIPS" the entry "NSS Internal PKCS #11 Module" on the left panel changes to "NSS Internal FIPS PKCS #11 Module". On Linux nothing happens, no change, no error, no warning, nothing (master password is set). Restarting the browser doesn't help. The same occurs with mozilla-1.7.3. Any ideas? Reproducible: Always Steps to Reproduce: 1. 2. 3.
This is a problem in the Mozilla client's official build process. Whenever it processes the NSS shared libraries/DLLs (for example, to strips the symbols or to generate Talkback symbol database), it needs to run the NSS utility "shlibsign" to regenerate the *.chk files. We fixed this problem before. Perhaps you are using a build before we fixed the problem. Perhaps the problem reappeared in new builds.
Assignee: wchang0222 → nobody
Component: Tools → Build Config
Product: NSS → Browser
QA Contact: bishakhabanerjee → core.build-config
Version: unspecified → Other Branch
As mozilla-1.7 was released I got it from ftp.mozilla.org and today I tested mozilla-1.7.3 from http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.3/mozilla-i686-pc-linux-gnu-1.7.3-full-installer.tar.gz and it also didn't work.
Here are the bugs where this problem was previously reported. 1. Bug 200775 2. Bug 212458 3. Bug 241374 I don't know if Leaf is still working on Mozilla. This bug needs to be assigned to the release engineer for Mozilla 1.7 and 1.7.3. I'll help him fix this bug.
Still doesn't work on 1.8a5 !!! Is anybody going to solve this? Is there a FIPS Maintainer? Thanks! Richard
Severity: normal → major
Richard, please do not set a "+" on flags. That's reserved. If you'd like to nominate a bug for fixing in a particular release, use the "?" flag. Thanks.
Enabling FIPS still doesn't work on 1.7.5. Is someone maintaining this?
OK, I volunteer to look into this. Chase, could you email to me or attach to this bug the build log file of the official Mozilla 1.7.5 Linux build?
Assignee: nobody → wtchang
The log files for the 1.7 branch nightlies are the builds of the 'maple' tinderbox that have a "D" link in the rectangle in: http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey-Branch (although that build may at some point move to the Mozilla1.7 tree instead)
Wan-Teh, The log from the 1.7.5 build can be found at http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey-Branch/1103293320.7660.gz&fulltext=1.
Richard, did you install Mozilla 1.7.5 using the installer (file name mozilla-i686-pc-linux-gnu-1.7.5-installer.tar.gz) or the "tar.gz format" (file name mozilla-i686-pc-linux-gnu-1.7.5.tar.gz)? If you used the installer, could you try another installation using the tar.gz format and see if FIPS mode can be enabled in that installation? You can download the tar.gz format from http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7.5/mozilla-i686-pc-linux-gnu-1.7.5.tar.gz
Chase, I believe I found where the problem is. On Linux, we use xpinstall/packager/unix/makexpi.pl to build the *.xpi files. (Please confirm.) makexpi.pl strips the files before creating the xpi. Whenever libsoftokn3.so is modified, the corresponding check file libsoftokn3.chk needs to be regenerated. The problem, I believe, is that makexpi.pl does not regenerate libsoftokn3.chk after stripping libsoftokn3.so. A quick-and-dirty fix is to modify makexpi.pl to remove from @libraryList pathnames that *contain* the following patterns: *softokn3* *freebl_hybrid_3* *freebl_pure32_3* I think this can be done in either the find_libraries or RecursiveStrip function. Could you implement this fix? The right solution is to regenerate the corresponding *.chk files if any of those files are stripped.
From what I see, Wan-Teh's correct that makexpi.pl is called by makeall.pl (which is called by deliver.pl) to create the Linux installer. This patch omits the libraries he mentions in this bug.
Comment on attachment 170504 [details] [diff] [review] Omit select libraries from stripping by makexpi.pl Committed on MOZILLA_1_7_BRANCH. Next round of builds tomorrow should have the fix included.
Comment on attachment 170504 [details] [diff] [review] Omit select libraries from stripping by makexpi.pl >+ # As stated by Wan-Teh, the true fix is to recreate the *.chk files for >+ # files of the form *softokn3*, *freebl_hybrid_3*, and *freebl_pure32_3* Please change the second line to # the softokn3, freebl_hybrid_3, and freebl_pure32_3 shared libraries I don't quite understand the comment "To be safe, we should probably regenerate all of the *.chk files for stripped libraries." The above three NSS shared libraries are the only libraries that have .chk files. 1) not stripping those three shared libraries, and 2) stripping them and regenerating their .chk files are equally safe.
(In reply to comment #10) > Richard, did you install Mozilla 1.7.5 using > the installer (file name mozilla-i686-pc-linux-gnu-1.7.5-installer.tar.gz) > or the "tar.gz format" (file name mozilla-i686-pc-linux-gnu-1.7.5.tar.gz)? I used the installer. > If you used the installer, could you try another installation > using the tar.gz format and see if FIPS mode can be enabled in > that installation? Done. With the tar.gz it works! Great! Thanks! I'll try the installer from the next nightly build to check if it's working now after the patch. Thanks again, Richard
Comment on attachment 170504 [details] [diff] [review] Omit select libraries from stripping by makexpi.pl I verified that this patch works. I'm using today's 2005-01-07-09-1.7 nightly build identified as: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050107. The trunk also needs this patch. The patch is a safe fix. Its only downside is that the libsoftokn3.so is not stripped, so the installer download size is slightly larger.
Attachment #170504 - Flags: review+
Comment on attachment 170504 [details] [diff] [review] Omit select libraries from stripping by makexpi.pl a=asa for checkin to the 1.8a6 trunk.
Attachment #170504 - Flags: approval1.8a6+
Comment on attachment 170504 [details] [diff] [review] Omit select libraries from stripping by makexpi.pl Committed an updated version of this patch on MOZILLA_1_7_BRANCH and HEAD.
unsetting blocking 1.8a6 flag beacause this no longer blocks the release.
Can we mark this RESOLVED and VERIFIED?
Here is an incomplete patch showing how to re-sign the NSS softoken shared libraries after stripping. It is incomplete in the following ways: 1. I had to copy the tool "shlibsign" to the staging area so it can be found by the makexpi.pl script. But the side effect is that we will be shipping the shlibsign tool, too. 2. I only deal with the LD_LIBRARY_PATH environment variable, which works on Linux and most Unix platforms. To be general, we also need to deal with SHLIB_PATH (32-bit HP-UX) and LIBPATH (AIX).
Marked the bug fixed. I will verify the fix (on the trunk) tomorrow.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha6
Verified on the trunk. 2005-01-09-07-trunk build: bad firstname.lastname@example.org checks in fix at 2005-01-10 01:43 2005-01-10-08-trunk build: good
Status: RESOLVED → VERIFIED
Here is the long-term fix I described earlier. Chase, please review and improve it. This fix is better than the short term fix because it strips the NSS softoken shared libraries to achieve the smallest download size. I have to move the RecursiveStrip function out of makexpi.pl so I have access to the shlibsign tool, which lives in $topobjdir/dist/bin. I did not deal with SHLIB_PATH (32-bit HP-UX) and LIBPATH (AIX). If makexpi.pl is being used on those platforms, we can handle them easily. I cleaned up the RecursiveStrip function by removing unused local variables. We should check this in on the trunk after Mozilla 1.8 Alpha 6 is done, and then backport it to the Mozilla 1.7 branch. Please suggest a superreviewer for this patch.
Comment on attachment 170934 [details] [diff] [review] Proposed long-term patch Handing r? on this over to bryner since we should make sure that moving the file stripping out of makexpi.pl and into deliver.pl is the right way to go. The alternative is to propagate $topobjdir to makexpi.pl which would be useful for future work.
Attachment #170934 - Flags: review?(cmp) → review?(bryner)
(In reply to comment #24) > I did not deal with SHLIB_PATH (32-bit HP-UX) > and LIBPATH (AIX). If makexpi.pl is being used > on those platforms, we can handle them easily. An alternative to address this is to run: $objdir/dist/bin/run-mozilla.sh $objdir/dist/bin/shlibsign -v -i ... which automatically sets the right *PATH variables on the various Unix platforms.
This patch uses run-mozilla.sh to execute the shlibsign command. (Thanks for the suggestion, Philip.) I also removed the unnecessary "cd $(DIST)/$(MOZ_PKG_APPNAME)" in two makefiles.
Attachment #171275 - Flags: review?(bryner) → review+
Comment on attachment 171275 [details] [diff] [review] Proposed long-term patch v1.1 Chase, could you also review this patch? (I know I'm abusing the "superreview" request.)
Attachment #171275 - Flags: superreview?(cmp)
Comment on attachment 171275 [details] [diff] [review] Proposed long-term patch v1.1 email@example.com
Attachment #171275 - Flags: superreview?(cmp) → superreview+
Comment on attachment 171275 [details] [diff] [review] Proposed long-term patch v1.1 I just checked in this patch on the trunk (Mozilla 1.8 Beta). I'd like to check this patch on the MOZILLA_1_7_BRANCH after some trunk testing.
Not going to hold the release here, but drivers would like to consider the patch. I will talk to wtc about it.
Flags: blocking1.7.6? → blocking1.7.6-
Comment on attachment 171275 [details] [diff] [review] Proposed long-term patch v1.1 a=caillon for 1.7.6 and aviary 1.0.1. Please land on both branches.
Is this going to land? time is short.
Comment on attachment 171275 [details] [diff] [review] Proposed long-term patch v1.1 Landed this on Aviary-1.0.1 on behalf of wtchang. Checking in toolkit/mozapps/installer/packager.mk; /cvsroot/mozilla/toolkit/mozapps/installer/packager.mk,v <-- packager.mk new revision: 126.96.36.199.2.2; previous revision: 188.8.131.52.2.1 done Checking in xpinstall/packager/Makefile.in; /cvsroot/mozilla/xpinstall/packager/Makefile.in,v <-- Makefile.in new revision: 184.108.40.206.2.2; previous revision: 220.127.116.11.2.1 done Checking in xpinstall/packager/unix/deliver.pl; /cvsroot/mozilla/xpinstall/packager/unix/deliver.pl,v <-- deliver.pl new revision: 18.104.22.168.2.1; previous revision: 22.214.171.124 done Checking in xpinstall/packager/unix/makexpi.pl; /cvsroot/mozilla/xpinstall/packager/unix/makexpi.pl,v <-- makexpi.pl new revision: 126.96.36.199.12.1; previous revision: 188.8.131.52 done The checkin was slightly different from this attachment because the aviary1.0.1 branch never got the interim fixes we had made on the 1.7 branch to RecursiveStrip() in makexpi.pl to put in-place a workaround fix. This patch is a full fix which supersedes those interim changes.
Wan-Teh, Can you please verify this fix works as expected by testing the aviary1.0.1 builds that appear tomorrow? They will be in: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-aviary1.0.1/ If you wish to be certain that you are testing a build that was produced on Friday, look for a directory '2005-02-18-XY-aviary1.0.1' within: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/ They are usually created between 7am and 12noon daily. Thanks.
I checked the patch in to the 1.7 branch too: Checking in xpinstall/packager/Makefile.in; /cvsroot/mozilla/xpinstall/packager/Makefile.in,v <-- Makefile.in new revision: 184.108.40.206; previous revision: 220.127.116.11 done Checking in xpinstall/packager/unix/deliver.pl; /cvsroot/mozilla/xpinstall/packager/unix/deliver.pl,v <-- deliver.pl new revision: 18.104.22.168; previous revision: 22.214.171.124 done Checking in xpinstall/packager/unix/makexpi.pl; /cvsroot/mozilla/xpinstall/packager/unix/makexpi.pl,v <-- makexpi.pl new revision: 126.96.36.199; previous revision: 188.8.131.52 done
I verified that the checkins on the Aviary 1.0.1 and Mozilla 1.7 branches are correct. Thanks, Chase and Christian, for your help. I haven't tested the builds yet. Note that this also needs to be checked in on the Aviary 1.0 branch because it is on the Aviary 1.0.1 branch. What kind of approval do I need?
Wan-Teh, I think mscott and bienvenu are managing that branch. You should talk to them.
You need to log in before you can comment on or make changes to this bug.