610431 - Init NSS earlier during Mozilla core startup, avoid XPCOM module indirection

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[Kai Engert [:KaiE:]]

This bug requests to simplify NSS initialization.

Instead of doing it indirectly at the time of the first PSM object creation, this bug proposes to perform the NSS init early during application startup.


Reasoning:

The interaction between the XPCOM module PSM and the C library NSS is difficult to maintain. We keep inventing band-aids.

It's expected that the XPCOM objects provided by PSM
- either are constructed correctly if NSS init was successful
- or construction fails if NSS init failed

In the past it was possible and necessary to build the Mozilla core without the use of the crypto library nss.

Because of this requirement, we tweaked the XPCOM-instantiation code in the PSM module, trying to ensure that we fulfil the above "either-or" promise.

Recently, things have changed:
- the older requirement of "optional crypto" has been dropped
- the Mozilla platform expects the crypto features to be available
- the parallelism of the code has increased

Because of the increased parallelism we start to see issues like bug 521849. That bug requires us to write tricky code, it's difficult to get it right.

Comment 1

[Kai Engert [:KaiE:]]

In the past, there has also been the argument that NSS init should be delayed past application startup, in order to speed up the startup process.

In my understanding things have changed, and the crypto features of NSS are now being used very early during application startup anyway.

Because of that, I'd argue, it's no longer necessary to delay NSS init.

And because decoupling NSS init from XPCOM indirection can simplify code, it should be done.

We could initialize NSS as soon as the code platform code knows the "profile directory" where all application files are stored (which includes the NSS files).

Comment 2

[Boris Zbarsky [:bzbarsky]]

> the crypto features of NSS are now being used very early during application
> startup anyway.

That's a bug we want to fix, not a feature, no?  Other than hashing, for the url classifier, are any other features used?

Comment 3

[Kai Engert [:KaiE:]]

Boris, IIUC you are against this simplification and want this as wontfix?

Comment 4

[Boris Zbarsky [:bzbarsky]]

I'm all for simplification if we've given up on getting NSS out of the startup path.  It's just not clear that we've given up on that.

Comment 5

[(dormant account)]

(In reply to comment #4)
> I'm all for simplification if we've given up on getting NSS out of the startup
> path.  It's just not clear that we've given up on that.

We haven't

Comment 6

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Kai, I agree we should simplify things so that Mozilla stops loading if NSS initialization fails since NSS isn't an optional component. But, can't we do that without making NSS load earlier?

I discussed with Robert the possibility of enabling Mozilla to use the NSSLowHash functionality for the implementation of our own hashing interface, avoiding the need for loading/initializing (most of) NSS, including Softoken. Robert even suggested that we consider embedding a copy of the FreeBL SHA-256 implementation into libxul, so that URL classifier doesn't force the loading of FreeBL. The point of doing so is to allow us to delay NSS library loading even longer in order to improve startup time.

Comment 7

[Kai Engert [:KaiE:]]

then this bug is wontfix and we must continue to live with the complicated psm init code.