421631 - shlibsign creates wrong output filename

Status: RESOLVED FIXED

(Toolkit Graveyard :: Build Config, defect)

Description

[Peter Weilbacher]

While trying to fix bug 421626 I stumbled again over the problem that shlibsign on OS/2 creates the wrong output filename while packaging. Instead of filename.chk it outputs filename.dll.chk. An example output is this:

[X:\trunk\fx\browser\installer]..\..\DIST\bin\shlibsign -v -i ../../dist/firefox/freebl3.dll 
Generating DSA Key Pair....Library File: ../../dist/firefox/freebl3.dll 318867 bytes
Check File: ../../dist/firefox/freebl3.dll.chk

This seems to be because in bug 240784 it was decided to fix the problem by uppercasing the default extension to .DLL. But I don't see a way to do the same in toolkit\mozapps\installer\packager.mk so I think this needs to be fixed in shlibsign. Probably by using case insensive comparison on OS/2. I don't really understand why it was decided against that in that old bug...

Comment 1

[Peter Weilbacher]

Attachment: try1

Hmm, this works for the signing but when trying to enable FIPS in SeaMonkey I still get

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIPKCS11ModuleDB.toggleFIPSMode]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://pippki/content/device_manager.js :: toggleFIPS :: line 504"  data: no]

I wonder if I am missing something.

Comment 2

[Julien Pierre]

Peter,

I haven't booted OS/2 in a while.
Can you please try to build NSS standalone ?
To do this, go to mozilla/security/nss and gmake nss_build_all .
You will need to fix the NSPR autoconf files in mozilla/nsprpub too as you probably now ...

As I remember it, this problem with the wrong chk file names did not exist. Please see if it does or not.
Also, to test FIPS mode from the command-line, do the following in mozilla/dist/OBJDIR/bin :

certutil -d . -N
modutil -dbdir . -fips true

It should tell you if it succeeded in setting FIPS mode or not.
Make sure you have BEGINLIBPATH properly set to point the new libs you just built (to ..\lib) .

Comment 3

[Peter Weilbacher]

Julien, thanks for the hints. I followed your guidelines and the modutil command nicely outputs "FIPS mode enabled." in the end, so it does work in principle.

I have seen the problem with the chk names on and off through the years. The Mozilla build process does it correctly, the output OBJDIR/dist/bin of a Firefox build contains e.g. {freebl3,softokn3}.{dll,chk} because DLL_SUFFIX is uppercase for NSS. (It probably gets lower-cased again by copying to the bin directory.) After stripping (on OS/2 using lxLite to strip and better compress the binaries) we have to re-sign and when doing that in toolkit/mozapps/installer/packager.mk we don't know that we have to pass an upper case extension. This has just gone unnoticed for the past two years or so because we didn't strip any more since the new packaging was put in place (moved from xpinstall/packager to the toolkit packager).

Another workaround would be to upper-case the extension of $(SOFTOKN) and $(FREEBL) in packager.mk for OS/2 only. Not sure which of these hacks is less ugly...

Comment 4

[Peter Weilbacher]

(In reply to comment #3)
> I followed your guidelines and the modutil command nicely outputs
> "FIPS mode enabled." in the end, so it does work in principle.

I now tried this with the latest Seamonkey OS/2 nightly from http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/contrib/2008-03-25-15-trunk/ and FIPS does now work after renaming freebl3.dll.chk to freebl3.chk and softokn3.dll.chk to softokn3.chk. So it was either something in my (patched) tree or in the specific nightly version that I was using.

Comment 5

[Peter Weilbacher]

Julien, do you want to see the packager.mk hack before you decide or are you happy with the fix of attachment 308120 [details] [diff] [review] after all?

Comment 6

[Julien Pierre]

I don't really like that attachment. Since you determine that modutil in the standalone NSS build works correctly, I would say that the problem is the subsequent renaming of the file in the packing in PSM. I would prefer that a change be made to PSM packaging to prevent that renaming.

Comment 7

[Julien Pierre]

Comment on attachment 308120 [details] [diff] [review]
try1

As previously discussed, I would prefer to avoid this change.

Comment 8

[Peter Weilbacher]

Attachment: uppercase extension for packaging

Well, nothing is ever renamed, but the Mozilla build system uses a lower case extension for DLLs which shlibsign doesn't like.

If I now artificially pass the upper case extension to shlibsign on OS/2, as in this patch, it also creates the correct output files. I find this even more ugly but it works.

Comment 9

[Julien Pierre]

Peter,

As far as I know the problem is OS/2 specific . The second patch you attached isn't. Many of the freebl DLLs in your 2nd patch don't exist on OS/2.

Comment 10

[Peter Weilbacher]

Attachment: uppercase extension for packaging, v2

Better?

Comment 11

[(not currently active) Ted Mielczarek]

Comment on attachment 316276 [details] [diff] [review]
uppercase extension for packaging, v2

Shouldn't you change the rest of the uses of DLL_SUFFIX for consistency?

Comment 12

[Peter Weilbacher]

(In reply to comment #11)
> (From update of attachment 316276 [details] [diff] [review])
> Shouldn't you change the rest of the uses of DLL_SUFFIX for consistency?

Ted, that was my first try (attachment 316179 [details] [diff] [review]) but Julien didn't like that. It doesn't hurt one way or the other.

-> we finally fix this in the toolkit packager so move to the right component

Comment 13

[Peter Weilbacher]

Comment on attachment 316276 [details] [diff] [review]
uppercase extension for packaging, v2

Change in the build config that only affects OS/2 (but is necessary to produce correct NSS signature files on that platform).

Comment 14

[Damon Sicore (:damons)]

Comment on attachment 316276 [details] [diff] [review]
uppercase extension for packaging, v2

a1.9+=damons

Comment 15

[Peter Weilbacher]

Fix checked into trunk.