Jason Duell Reporter
	Description • 15 years ago

So we're now shipping HTTPS requests to the chrome process.  To save memory we want to turn off NSS in the children.

This may be as simple as just finding the init code and disabling it if #defined MOZ_IPC && IsNeckoChild() == true.   But first we need to know if any other code uses NSS in the child besides HTTPS. Dougt mentioned that some things might use NSS via PSM.

	Jason Duell Reporter
	Comment 1 • 15 years ago

http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/public/

has the PSM interfaces.  I didn't see any obvious clients of it in mxr that we need to worry about, but didn't search extensively.

We could probably use someone who actually knows the NSS code to help us a little with this.  Bueller?

	Jason Duell Reporter
	Comment 2 • 15 years ago

Over to bsmedberg who'll add a fatal assert if NSS is touched, so we can see what's using NSS now that we've removed HTTPS from content.

The most likely culprit is the JS crypto code: I've opened bug 561244 for that.

Rumor has it that if nothing uses NSS, it doesn't get initialized and hog memory:  we should verify that.

	Benjamin Smedberg Assignee
	Comment 3 • 14 years ago

This is the most basic thing, which prevents any PSM classes from being initialized.

	Honza Bambas (:mayhemer)
	Comment 4 • 14 years ago

Adding dep on the channel classifier being run in the chrome process that heavily uses crypto code.

	Honza Bambas (:mayhemer)
	Comment 5 • 14 years ago

Comment on attachment 445120 [details] [diff] [review]
Disable NSS/PSM in the content process, rev. 1

After all bugs blocking this one lands we can give this a try.  ATM I don't about anything else using nss.

	Honza Bambas (:mayhemer)
	Comment 6 • 14 years ago

Security UI on the child process is collecting all information about the security state and forwards that to the TabParent.  One of this information is the EV (extended validation) status.  The check cannot be done on the child process because it requires the nss be initialized and doesn't work on the child process anyway (needs access to the cert database of the profile).

Bug 536301 is going to move this check to the parent process.  W/o it we don't have the EV status visible.

	Justin Wood (:Callek)
	Comment 7 • 14 years ago

This patch should fix the shared build bustage. This affects c-c since we don't --enable-libxul nor do we have xul.lib before this dir's link happens.

It is a sorta-hack since MOZ_IPC is not defined unless we are libxul, but since this code is not really useful unless MOZ_IPC is defined anyway, it doesn't hurt anything to ifdef based on it.

	Robert Kaiser
	Comment 8 • 14 years ago

Gah. It's not like we like having MOZ_IPC disabled in our builds, but if we must, it would really be nice if it at least builds. Thanks, Justin, for that patch!

	Justin Wood (:Callek)
	Comment 9 • 14 years ago

Comment on attachment 464204 [details] [diff] [review]
Fix for shared build bustage

Hoping that honza might be around soon to give this a review so comm-central can go back to green.

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 14 years ago

Comment on attachment 464204 [details] [diff] [review]
Fix for shared build bustage

r+a=me; this is breaking my builds.

	Justin Wood (:Callek)
	Comment 11 • 14 years ago

C(In reply to comment #9)
> Comment on attachment 464204 [details] [diff] [review]
> Fix for shared build bustage

Checked in: http://hg.mozilla.org/mozilla-central/rev/be806599987a

	Benjamin Smedberg Assignee
	Comment 12 • 14 years ago

http://hg.mozilla.org/mozilla-central/rev/33939a23c4b1