Closed Bug 911289 Opened 11 years ago Closed 11 years ago

newer signmar fails to initialize nss config directory

Categories

(Toolkit :: Application Update, defect)

Product:
Toolkit
Component:
Application Update
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: bhearsum, Assigned: bbondy)

References

Details

During an upgrade of our signing servers we rebuilt signmar and found that it didn't work. Specifically, we got this error: /tools/signmar/bin/signmar -d /builds/signing/dep-key-signing-server/secrets/mar -n dep1 -s /tools/signing-test-files/test.mar /tmp/tmp_NjGMd/test.mar.tmp2 ERROR: Could not initialize NSS ERROR: Could not init config dir: /builds/signing/dep-key-signing-server/secrets/mar The old version of signmar still works fine if copied to the new machine. I don't have the exact rev of the working version, but it was built near the start of April, 2012 (presumably off of mozilla-central), so I'd guess that it's Gecko 14 or 15 based. The new (non-working) version was built from the Firefox 19 source tarball.
I'm wondering if it is related to the nss dir being created initially with an older NSS version. And the newer signmar beling linked to the new nss config dir. Or it could just be some random bug and tests aren't running. I'll investigate, thanks for posting
Assignee: nobody → netzen
I failed to build 14, 15, or 23 in the few minutes I have - i'll try again next week.
It doesn't look like 14 or 15 will build correctly, and #build seemed uninterested in the project, so let's try to get this fixed and then build tip?
I just rebuilt one of our MAR cert stores with a Gecko 23-based certutil and I'm still getting the same error from the Gecko 19-based signmar.
So I tried this out on Windows but it's working correctly. I think maybe what's going on is that the new machine has the wrong shared library dependencies for NSS? If you want I can also try it out on OSX tomorrow?
With Ben's OK, I can get you access to the host in question, if that helps.
I have it building on OSX now, I'll let you know how that works, then I'll have you test with the same exact command and nss db to see if that works on your end.
OK so I looked into this more and reproduced the problem on OSX. The issue is that you need to also copy the *.dylib files that are in dist/bin/. Or you can execute signmar from exactly within dist/bin. I'll see if I can statically link to this instead to avoid this happening again. NSS_Initialize fails with an errono of file not found when one or more of the needed dylibs are wrong or missing. So you have a temp work around right now at least. But I'm still looking into seeing if I can statically link everything together or not.
Hi bsmith, Is it possible to not rely on the dylib files and statically link everything inside signmar? We do specify libnss3.a already. libnss3.dylib also seems to rely on mozglue dylib which we try to exclude from signmar when we build it too. http://dxr.mozilla.org/mozilla-central/source/modules/libmar/tool/Makefile.in#l43
Flags: needinfo?(brian)
The dynamic linking wouldn't be so bad if the error message was more closely related to the problem. Is that easier to change?
I think the mozglue dependency may be what's new in NSS, because we do copy the dylib for nss3 before running tests, but we never had to copy mozglue and friends. Maybe we need > MOZ_GLUE_LDFLAGS = > MOZ_GLUE_PROGRAM_LDFLAGS = When building nss3?
(In reply to Dustin J. Mitchell [:dustin] from comment #10) > The dynamic linking wouldn't be so bad if the error message was more closely > related to the problem. Is that easier to change? Well the call to NSS fails and returns -1, and errono says file not found. I can just output extra info about potential causes of failures to initialize NSS but I'd like bmsith to weigh in first.
(In reply to Brian R. Bondy [:bbondy] from comment #9) > Is it possible to not rely on the dylib files and statically link everything > inside signmar? We do specify libnss3.a already. Google does build some kind of statically-linked NSS, however the NSS build system doesn't support static linking. If it is just an issue with our internal infrastructure then I don't think it is worth trying to build and support a statically-linked NSS yet, thought it is something we should eventually do. libnss3 is actually easier than the rest. The real problem is softoken and freebl. If we need a statically-linked NSS for the purposes of verifying MAR signatures on the client, then I suggest we do what we did on Windows and use OS-provided APIs instead of NSS for that--including OS-provided NSS on Linux, I guess. > libnss3.dylib also seems to rely on mozglue dylib which we try to exclude > from signmar when we build it too. You should be able to swap in stock NSS shared libraries (the kind you get from doing a standalone build of NSS) as a substitute for the combined libnss3 we now build as part of Gecko's build system.
Flags: needinfo?(brian)
For client MAR verification I thought our bundle already uses NSS, so I wasn't anticipating a problem there. I haven't done testing with the patches that need to be landed yet though. Do you anticipate problems there? This bug is only for the internal infrastructure though, so WONTFIX'ing based on your your suggestion. Machines should use the newer shared libraries to get around the problem.
Status: NEW → RESOLVED
Closed: 11 years ago
Flags: needinfo?(brian)
Resolution: --- → WONTFIX
(In reply to Brian R. Bondy [:bbondy] from comment #14) > For client MAR verification I thought our bundle already uses NSS, so I > wasn't anticipating a problem there. I haven't done testing with the patches > that need to be landed yet though. Do you anticipate problems there? Presumably everywhere other than Linux allows you to replace a shared library that is in use, so you should probably be OK.
Flags: needinfo?(brian)
You need to log in before you can comment on or make changes to this bug.