Closed Bug 262822 Opened 20 years ago Closed 20 years ago

FIPS can't be enabled

Categories

(SeaMonkey :: Build Config, defect)

Other Branch
x86
Linux
defect
Not set
major

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)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Product: Browser → Seamonkey
Still doesn't work on 1.8a5 !!!
Is anybody going to solve this?
Is there a FIPS Maintainer?

Thanks! Richard
Severity: normal → major
Flags: blocking1.8a6-
Flags: blocking1.7.6-
Flags: blocking1.7.5-
Flags: blocking1.8a6-
Flags: blocking1.8a6+
Flags: blocking1.7.6-
Flags: blocking1.7.6+
Flags: blocking1.7.5-
Flags: blocking1.7.5+
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+
Enabling FIPS still doesn't work on 1.7.5.
Is someone maintaining this?
Flags: blocking1.8b?
Flags: blocking1.8a6?
Flags: blocking1.7.6?
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)
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
Flags: blocking1.8b?
Flags: blocking1.8a6?
Flags: blocking1.8a6+
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.
Flags: blocking1.8a6+
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: 20 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha6
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
Attached patch Proposed long-term patch (obsolete) — Splinter Review
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.
Attachment #170854 - Attachment is obsolete: true
Attachment #170934 - Flags: review?(cmp)
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 #170934 - Attachment is obsolete: true
Attachment #171275 - Flags: review?(bryner)
Attachment #170934 - Flags: review?(bryner)
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

sr=cmp@mozilla.org
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.
Attachment #171275 - Flags: approval1.7.6?
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.
Attachment #171275 - Flags: approval1.7.6?
Attachment #171275 - Flags: approval1.7.6+
Attachment #171275 - Flags: approval-aviary1.0.1+
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: 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.
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: 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
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.

Attachment

General

Creator:
Created:
Updated:
Size: