Closed Bug 370693 Opened 13 years ago Closed 13 years ago nightly bits broken, Failure to use crypto with FIPS mode


(Core :: Security: PSM, defect)

Not set





(Reporter: KaiE, Assigned: KaiE)





(1 file, 1 obsolete file)

With the latest Firefox trunk code we fail to switch into FIPS mode, or, when using a profile that has FIPS already enabled, we fail to init the crypto component.
So far I was able to reproduce on both Linux and Windows, using the nightly trunk builds available from

To my surprise, I was NOT yet able to reproduce this with my local builds.
Still investigating.
This appears to be a problem with the build system used on infrastructure to produce the nightly download bits.

I suspect the distributed NSS libraries to not match the distributed *.chk files.

As said in comment 1, a downloaded Firefox trunk build does not allow to use FIPS mode. Neither windows nor Linux.

I used such a broken downloaded Linux build, I replaced all NSS libraries and chk files with files from my own local build, and that made it work.
Summary: Failure to use crypto with FIPS mode → nightly bits broken, Failure to use crypto with FIPS mode
Duplicate of this bug: 370476
Using a full-time display of the library and checksum files:

[kengert@kaiez1:/tmp/fips/head/firefox]$ ls -ltr --full-time libsoftokn3.* libfreebl3.*
kengert kengert    476 2007-03-14 06:03:04.000000000 -0700 libsoftokn3.chk
kengert kengert    476 2007-03-14 06:03:04.000000000 -0700 libfreebl3.chk
kengert kengert 296128 2007-03-14 06:03:07.000000000 -0700
kengert kengert 231408 2007-03-14 06:03:07.000000000 -0700

The .so files are 3 seconds newer than the .chk files.
This means, after we produced the software-integrity-test checksum files, some other process modified the .so files.

As a result the .chk files no longer match and the runtime integrity test fails.

I confirmed this happens with both Firefox and Thunderbird on trunk.

(FF and TB on stable 1.8 branch work fine. SeaMonkey works fine on both trunk and branch.)

We need to track down what happens before the official binaries get produced.
I think I found the machines that produce the nightly trunk binaries and looked at their tinderbox logfiles.

The problem seems related to building in-tree and wrong pathnames to shlibshign/run-mozilla.
There is a pending patch that helps on Linux, need more testing for Windows.
Read on for more details.

Linux argo-vm:

The following failure explains the bug:
    Stripping package directory...
    signing nss libraries Cannot execute ../../nss/shlibsign. Cannot execute ../../nss/shlibsign.

Stripping changes the .so file.
Afterwards we must run shlibsign again, in order to create correct .chk files.
Running shlibsign fails.

The build does not use a separate objdir, but builds in-tree, inside the source directories.

With an objdir we get objdir/nss/shlibsign output.
With an objdir, when running make in objdir/browser/installer, the relative path ../../nss/shlibsign will work.

With an in-tree build, we run make from mozilla/browser/installer. The relative path fails, because there is no mozilla/nss output directory. The real path is mozilla/dist/bin/shlibsign.

The problem is in toolkit/mozapps/installer/
I found that this is caused by a "workaround" that was applied by Vladimir on 2006-02-06.
I found that bug 249782 already has the correct fix for this issue, attached by Wan-Teh on 2006-12-06 and asked Vladimir for review (bug 249782 attachment 247764 [details] [diff] [review]).

I tested the fix locally and it works for me, both in an "in-tree" build and in an "objdir" build.

Windows fx-win32-tbox:
Similar problem. Logfile:

  Stripping package directory...
  signing nss libraries
  /bin/sh: ../../dist/bin/ No such file or directory
  /bin/sh: ../../dist/bin/ No such file or directory

I'm don't understand why can not be found.
The patch does not change how is accessed, so maybe that is a separate problem?

Ideas? I might build myself to check.
The Windows part is a bit confusing.
The signing action tries to call - yes, even on Windows.
But is not present in dist area.

I was able to make it work (locally) using
  cp -i build/unix/ dist/bin

So the following series of actions fixes windows for me:
- apply patch
- build in-tree
- cp -i mozilla/build/unix/ mozilla/dist/bin
- cd mozilla/browser/installer
- make

I still need to test whether it works in a objdir build, too. is missing on the 1.8 branch builds, too.
Looking at the logfiles of the 1.8 branch tinderbox Firefox nightly build, we get the same error message about

The confusing part is: Why does FIPS mode work on 1.8 branch Firefox builds?
Attached patch Patch v1 (obsolete) — Splinter Review
I learned that on Windows, the is simply not necessary. It works to run the executable directly.

I've produced a modified patch that will execute shlibsign directly on Windows, and continues to use elsewhere.

This patch combines the necessary fix with another conflicting not-yet-reviewed patch, that was originally attached to bug 249782.
Attachment #259902 - Flags: superreview?(benjamin)
Attachment #259902 - Flags: review?(vladimir)
Comment on attachment 259902 [details] [diff] [review]
Patch v1

To run a program in mozilla, use $(RUN_TEST_PROGRAM) progname. That will automatically use if needed:
Attachment #259902 - Flags: superreview?(benjamin)
Attachment #259902 - Flags: superreview-
Attachment #259902 - Flags: review?(vladimir)
Attached patch Patch v2Splinter Review
Thanks, Benjamin!
This patch has the change you proposed.
I tested it on Linux and Windows, both objdir and in-tree, and it works fine for me.
Attachment #259902 - Attachment is obsolete: true
Attachment #259916 - Flags: superreview?(vladimir)
Attachment #259916 - Flags: review?(benjamin)
Since we get the error message on 1.8 branch, too. I wonder if we should bother to change to RUN_TEST_PROGRAM on the branch, too?
QA Contact: psm
Attachment #259916 - Flags: review?(benjamin) → review+
Attachment #259916 - Flags: superreview?(vladimir)
Ben, thanks for reviewing.

Checked in, marking fixed on trunk.
Closed: 13 years ago
Resolution: --- → FIXED
Depends on: vs2005
Depends on: 408205
You need to log in before you can comment on or make changes to this bug.