Closed Bug 421631 Opened 15 years ago Closed 15 years ago

shlibsign creates wrong output filename


(Toolkit Graveyard :: Build Config, defect)

Not set


(Not tracked)



(Reporter: mozilla, Assigned: mozilla)



(2 files, 1 obsolete file)

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\ 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...
Attached patch try1Splinter Review
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.
Assignee: nobody → mozilla
Ever confirmed: true
Attachment #308120 - Flags: review?(julien.pierre.boogz)

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) .
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/ 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 for OS/2 only. Not sure which of these hacks is less ugly...
(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 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.
Julien, do you want to see the hack before you decide or are you happy with the fix of attachment 308120 [details] [diff] [review] after all?
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 on attachment 308120 [details] [diff] [review]

As previously discussed, I would prefer to avoid this change.
Attachment #308120 - Flags: review?(julien.pierre.boogz) → review-
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.
Attachment #316179 - Flags: review?(ted.mielczarek)

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.
Attachment #316179 - Attachment is obsolete: true
Attachment #316276 - Flags: review?(ted.mielczarek)
Attachment #316179 - Flags: review?(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?
Attachment #316276 - Flags: review?(ted.mielczarek) → review+
(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
Component: Tools → Build Config
Product: NSS → Toolkit
Version: 3.12 → Trunk
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).
Attachment #316276 - Flags: approval1.9?
Comment on attachment 316276 [details] [diff] [review]
uppercase extension for packaging, v2

Attachment #316276 - Flags: approval1.9? → approval1.9+
Fix checked into trunk.
Closed: 15 years ago
Resolution: --- → FIXED
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.