Closed Bug 370693 Opened 13 years ago Closed 13 years ago
.org nightly bits broken, Failure to use crypto with FIPS mode
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 mozilla.org 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 Mozilla.org 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 → Mozilla.org nightly bits broken, Failure to use crypto with FIPS mode
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 libsoftokn3.so kengert kengert 231408 2007-03-14 06:03:07.000000000 -0700 libfreebl3.so 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. Summary: 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 run-mozilla.sh: Cannot execute ../../nss/shlibsign. run-mozilla.sh: 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/packager.mk 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/run-mozilla.sh: No such file or directory /bin/sh: ../../dist/bin/run-mozilla.sh: No such file or directory I'm don't understand why run-mozilla.sh can not be found. The patch does not change how run-mozilla.sh 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 run-mozilla.sh - yes, even on Windows. But run-mozilla.sh is not present in dist area. I was able to make it work (locally) using cp -i build/unix/run-mozilla.sh dist/bin So the following series of actions fixes windows for me: - apply patch - build in-tree - cp -i mozilla/build/unix/run-mozilla.sh mozilla/dist/bin - cd mozilla/browser/installer - make I still need to test whether it works in a objdir build, too.
run-mozilla.sh 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 run-mozilla.sh The confusing part is: Why does FIPS mode work on 1.8 branch Firefox builds?
I learned that on Windows, the run-mozilla.sh 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 run-mozilla.sh elsewhere. This patch combines the necessary fix with another conflicting not-yet-reviewed patch, that was originally attached to bug 249782.
Comment on attachment 259902 [details] [diff] [review] Patch v1 To run a program in mozilla, use $(RUN_TEST_PROGRAM) progname. That will automatically use run-mozilla.sh if needed: http://lxr.mozilla.org/mozilla/source/config/config.mk#881
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.
Since we get the error message on 1.8 branch, too. I wonder if we should bother to change run-mozilla.sh to RUN_TEST_PROGRAM on the branch, too?
Ben, thanks for reviewing. Checked in, marking fixed on trunk.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.