Initialization of PKCS#11 crypto module changed since NSS 3.12.5?

[Bernhard Thalmayr]

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).

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?

TIA,
Bernhard

[Wan-Teh Chang]

On Thu, Apr 21, 2011 at 1:06 PM, Bernhard Thalmayr
<bernhard...@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.

> 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.

Wan-Teh

[Robert Relyea]

On 04/21/2011 02:14 PM, Wan-Teh Chang wrote:
> On Thu, Apr 21, 2011 at 1:06 PM, Bernhard Thalmayr
> <bernhard...@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