Closed
Bug 262822
Opened 19 years ago
Closed 19 years ago
FIPS can't be enabled
Categories
(SeaMonkey :: Build Config, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla1.8alpha6
People
(Reporter: r.ems, Assigned: wtc)
Details
(Keywords: fixed-aviary1.0.1, fixed1.7.6)
Attachments
(2 files, 2 obsolete files)
1.11 KB,
patch
|
wtc
:
review+
asa
:
approval1.8a6+
|
Details | Diff | Splinter Review |
6.25 KB,
patch
|
bryner
:
review+
chase
:
superreview+
caillon
:
approval-aviary1.0.1+
caillon
:
approval1.7.6+
|
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.
Assignee | ||
Comment 1•19 years ago
|
||
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
Reporter | ||
Comment 2•19 years ago
|
||
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.
Assignee | ||
Comment 3•19 years ago
|
||
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.
Updated•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•19 years ago
|
Product: Browser → Seamonkey
Reporter | ||
Comment 4•19 years ago
|
||
Still doesn't work on 1.8a5 !!! Is anybody going to solve this? Is there a FIPS Maintainer? Thanks! Richard
Severity: normal → major
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.8a6-
Flags: blocking1.7.6-
Flags: blocking1.7.5-
Reporter | ||
Updated•19 years ago
|
Flags: blocking1.8a6-
Flags: blocking1.8a6+
Flags: blocking1.7.6-
Flags: blocking1.7.6+
Flags: blocking1.7.5-
Flags: blocking1.7.5+
Comment 5•19 years ago
|
||
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.
Flags: blocking1.8a6+
Flags: blocking1.7.6+
Flags: blocking1.7.5+
Reporter | ||
Comment 6•19 years ago
|
||
Enabling FIPS still doesn't work on 1.7.5. Is someone maintaining this?
Flags: blocking1.8b?
Flags: blocking1.8a6?
Flags: blocking1.7.6?
Assignee | ||
Comment 7•19 years ago
|
||
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
Comment 8•19 years ago
|
||
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)
Comment 9•19 years ago
|
||
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.
Assignee | ||
Comment 10•19 years ago
|
||
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
Assignee | ||
Comment 11•19 years ago
|
||
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.
Comment 12•19 years ago
|
||
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 13•19 years ago
|
||
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.
Assignee | ||
Comment 14•19 years ago
|
||
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.
Reporter | ||
Comment 15•19 years ago
|
||
(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
Updated•19 years ago
|
Flags: blocking1.8b?
Flags: blocking1.8a6?
Flags: blocking1.8a6+
Assignee | ||
Comment 16•19 years ago
|
||
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 17•19 years ago
|
||
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 18•19 years ago
|
||
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.
Comment 19•19 years ago
|
||
unsetting blocking 1.8a6 flag beacause this no longer blocks the release.
Flags: blocking1.8a6+
Comment 20•19 years ago
|
||
Can we mark this RESOLVED and VERIFIED?
Assignee | ||
Comment 21•19 years ago
|
||
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).
Assignee | ||
Comment 22•19 years ago
|
||
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
Assignee | ||
Comment 23•19 years ago
|
||
Verified on the trunk. 2005-01-09-07-trunk build: bad cmp@mozilla.org checks in fix at 2005-01-10 01:43 2005-01-10-08-trunk build: good
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 24•19 years ago
|
||
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.
Assignee | ||
Updated•19 years ago
|
Attachment #170854 -
Attachment is obsolete: true
Attachment #170934 -
Flags: review?(cmp)
Comment 25•19 years ago
|
||
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)
Comment 26•19 years ago
|
||
(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.
Assignee | ||
Comment 27•19 years ago
|
||
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 #170934 -
Attachment is obsolete: true
Attachment #171275 -
Flags: review?(bryner)
Assignee | ||
Updated•19 years ago
|
Attachment #170934 -
Flags: review?(bryner)
Updated•19 years ago
|
Attachment #171275 -
Flags: review?(bryner) → review+
Assignee | ||
Comment 28•19 years ago
|
||
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 29•19 years ago
|
||
Comment on attachment 171275 [details] [diff] [review] Proposed long-term patch v1.1 sr=cmp@mozilla.org
Attachment #171275 -
Flags: superreview?(cmp) → superreview+
Assignee | ||
Comment 30•19 years ago
|
||
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.
Attachment #171275 -
Flags: approval1.7.6?
Comment 31•19 years ago
|
||
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 32•19 years ago
|
||
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.
Attachment #171275 -
Flags: approval1.7.6?
Attachment #171275 -
Flags: approval1.7.6+
Attachment #171275 -
Flags: approval-aviary1.0.1+
Comment 33•19 years ago
|
||
Is this going to land? time is short.
Comment 34•19 years ago
|
||
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: 1.1.2.2.2.2; previous revision: 1.1.2.2.2.1 done Checking in xpinstall/packager/Makefile.in; /cvsroot/mozilla/xpinstall/packager/Makefile.in,v <-- Makefile.in new revision: 1.49.6.7.2.2; previous revision: 1.49.6.7.2.1 done Checking in xpinstall/packager/unix/deliver.pl; /cvsroot/mozilla/xpinstall/packager/unix/deliver.pl,v <-- deliver.pl new revision: 1.13.6.1.2.1; previous revision: 1.13.6.1 done Checking in xpinstall/packager/unix/makexpi.pl; /cvsroot/mozilla/xpinstall/packager/unix/makexpi.pl,v <-- makexpi.pl new revision: 1.8.2.1.12.1; previous revision: 1.8.2.1 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.
Updated•19 years ago
|
Keywords: fixed-aviary1.0.1
Comment 35•19 years ago
|
||
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.
Comment 36•19 years ago
|
||
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: 1.49.2.4; previous revision: 1.49.2.3 done Checking in xpinstall/packager/unix/deliver.pl; /cvsroot/mozilla/xpinstall/packager/unix/deliver.pl,v <-- deliver.pl new revision: 1.13.2.2; previous revision: 1.13.2.1 done Checking in xpinstall/packager/unix/makexpi.pl; /cvsroot/mozilla/xpinstall/packager/unix/makexpi.pl,v <-- makexpi.pl new revision: 1.8.2.5; previous revision: 1.8.2.4 done
Keywords: fixed1.7.6
Assignee | ||
Comment 37•19 years ago
|
||
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?
Comment 38•19 years ago
|
||
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.
Description
•