On 04/21/2011 02:14 PM, Wan-Teh Chang wrote: > On Thu, Apr 21, 2011 at 1:06 PM, Bernhard Thalmayr > <bernhard.thalm...@painstakingminds.com> wrote: >> Hi experts, according to >> 'https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables' >> PKCS#11 crypto module will throw an error if not initialized by the process >> which will use it (even it has been initialized by the parent process). > I guess you're referring to the NSS_STRICT_NOFORK environment variable. The semantic was added to NSS 3.12.6. It was modified in NSS 3.12.9 with the environment variable to control it's behavior. >> It seems this behaviour has been changed with NSS 3.12.9 or >> (3.12.8,3.12.7,3.12.6) as I don't get an error using NSS 3.12.9 but NSS >> 3.12.5. >> >> I've read all available release notes but could not find a hint when and why >> this has changed. >> >> So the question arises ...do I have to change the way of initializing NSS or >> not? > In the bugs fixed in NSS 3.12.6 - 3.12.9: > https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&classification=Components&query_format=advanced&product=NSS&target_milestone=3.12.6&target_milestone=3.12.7&target_milestone=3.12.8&target_milestone=3.12.9 > > I believe this bug, fixed in NSS 3.12.9, causes the change you observed: > https://bugzilla.mozilla.org/show_bug.cgi?id=610843 > It seems that you need to call the new SECMOD_RestartModules function > in the child process. Yes, it's not safe to initialize NSS and fork(). That is because the results are undefined in PKCS #11. Because we have ran into problems with people doing this, we added code to enforce the PKCS #11 semantics in our softoken PKCS #11 module.
The old way of handling parent/child relationship is to shut down NSS in and reinitialize in the client. This can be tricky if the parent has open NSS objects, so we've added the function SECMOD_RestartModules which you can call in the client. NOTE that any previously existing handles (keys, ssl sessions, etc.) started in the parent will be lost in the client after this call. The NSS_STRICT_NOFORK allows 2 modifications to this semantic. If you set NSS_STRICT_NOFORK to 1, then softoken will actually crash on this case. This is intended to help debug where you may have misbehaving code. If you set NSS_STRICT_NOFORK to DISABLED, you will disable the fork() check semantic. For the most part this is a stopgap issue, as softoken is not the only PKCS #11 module that has this fork() semantic. Better to use SECMOD_RestartModules() in the client. bob
-- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
