262822 - FIPS can't be enabled

Status: VERIFIED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Richard Ems]

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.

Comment 1

[Wan-Teh Chang]

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.

Comment 2

[Richard Ems]

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.

Comment 3

[Wan-Teh Chang]

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.

Comment 4

[Richard Ems]

Still doesn't work on 1.8a5 !!!
Is anybody going to solve this?
Is there a FIPS Maintainer?

Thanks! Richard

Comment 5

[Asa Dotzler [:asa]]

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.

Comment 6

[Richard Ems]

Enabling FIPS still doesn't work on 1.7.5.
Is someone maintaining this?

Comment 7

[Wan-Teh Chang]

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?

Comment 8

[David Baron :dbaron:]

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

[Chase Phillips]

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.

Comment 10

[Wan-Teh Chang]

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

Comment 11

[Wan-Teh Chang]

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

[Chase Phillips]

Attachment: Omit select libraries from stripping by makexpi.pl

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

[Chase Phillips]

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 14

[Wan-Teh Chang]

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.

Comment 15

[Richard Ems]

(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 16

[Wan-Teh Chang]

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.

Comment 17

[Asa Dotzler [:asa]]

Comment on attachment 170504 [details] [diff] [review]
Omit select libraries from stripping by makexpi.pl

a=asa for checkin to the 1.8a6 trunk.

Comment 18

[Chase Phillips]

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

[Asa Dotzler [:asa]]

unsetting blocking 1.8a6 flag beacause this no longer blocks the release.

Comment 20

[Chase Phillips]

Can we mark this RESOLVED and VERIFIED?

Comment 21

[Wan-Teh Chang]

Attachment: An incomplete patch showing re-signing the NSS softoken libraries after stripping

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).

Comment 22

[Wan-Teh Chang]

Marked the bug fixed.  I will verify the fix (on the
trunk) tomorrow.

Comment 23

[Wan-Teh Chang]

Verified on the trunk.

2005-01-09-07-trunk build: bad
[e-mail] checks in fix at 2005-01-10 01:43
2005-01-10-08-trunk build: good

Comment 24

[Wan-Teh Chang]

Attachment: Proposed long-term patch

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 25

[Chase Phillips]

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.

Comment 26

[Philip K. Warren]

(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.

Comment 27

[Wan-Teh Chang]

Attachment: Proposed long-term patch v1.1

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.

Comment 28

[Wan-Teh Chang]

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.)

Comment 29

[Chase Phillips]

Comment on attachment 171275 [details] [diff] [review]
Proposed long-term patch v1.1

sr=[e-mail]

Comment 30

[Wan-Teh Chang]

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.

Comment 31

[Christopher Aillon (sabbatical, not receiving bugmail)]

Not going to hold the release here, but drivers would like to consider the
patch.  I will talk to wtc about it.

Comment 32

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 33

[Daniel Veditz [:dveditz]]

Is this going to land? time is short.

Comment 34

[Chase Phillips]

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.

Comment 35

[Chase Phillips]

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

[Christian :Biesinger (don't email me, ping me on IRC)]

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

Comment 37

[Wan-Teh Chang]

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

[Christopher Aillon (sabbatical, not receiving bugmail)]

Wan-Teh, I think mscott and bienvenu are managing that branch.  You should talk
to them.