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
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?
I guess you're referring to the NSS_STRICT_NOFORK environment variable.
> 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
> 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
In the bugs fixed in NSS 3.12.6 - 3.12.9:
I believe this bug, fixed in NSS 3.12.9, causes the change you observed:
It seems that you need to call the new SECMOD_RestartModules function
in the child process.
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.