Closed Bug 212458 Opened 18 years ago Closed 12 years ago

Cannot initialize the security component in FIPS mode or enable FIPS in Mozilla 1.4

Categories

(SeaMonkey :: Build Config, defect, P3)

PowerPC
macOS

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: wtc, Unassigned)

Details

The build is Mozilla 1.4 for Mac OS X.

There are two symptoms of this bug.

1. If the security component (NSS) was previously in FIPS mode,
the security component can't be initialized after upgrading
to Mozilla 1.4.

2. If the security component (NSS) was previously in non-FIPS mode,
we can't enable FIPS after upgrading to Mozilla 1.4.

The bug is that libsoftokn3.dylib was modified by the release build
process but its FIPS check file libsoftokn3.chk (newly introduced
in NSS 3.8/Mozilla 1.4) was not regenerated.

To fix this bug, we need to find out where in Mozilla's release
build process for Mac OS X we modify libsoftokn3.dylib.  This could
be things like stripping the .dylib's of symbols, rebasing or
prebinding, or splitting the symbols for Talkback.  Once we know
where that is done, we need to use the NSS tool 'shlibsign' to
regenerate libsoftokn3.chk.

The Windows and Linux builds of Mozilla 1.4 do not have this problem.
punting to jj.  Needs to go on the trunk and the 1.4 branch.
Assignee: mozbugs-build → jj
Target Milestone: --- → mozilla1.5beta
Version: 1.4 Branch → Trunk
Bingo. we do strip symbols from dylibs (using strip -S) before packaging Mozilla.
I don't know much about shlibsign nor libsoftokn3.chk yet, but if there is an
additional step to run the the release packaging automation, that should be easy
to implement.
I just need some directions on how to do this. Leaf? Wan-Teh?
Status: NEW → ASSIGNED
over to chase.

this might be fixed with the switch to the tinderbox release scripts since I
believe it re-signs the nss libraries after stripping.
Assignee: jje → cmp
Status: ASSIGNED → NEW
Priority: -- → P3
QA Contact: granrosebugs → leaf
Target Milestone: mozilla1.5beta → ---
Product: Browser → Seamonkey
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
Mass re-assign of bugs that aren't on the build team radar, so bugs assigned to build@mozilla-org.bugs reflects reality.

If there is a bug you really think we need to be looking at, please *email* build@mozilla.org with a bug number and explanation.
Assignee: build → nobody
Mozilla 1.4 is long gone. Please reopen if you see the problem on current trunk builds.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.