Closed Bug 559711 Opened 13 years ago Closed 12 years ago
e10s HTTP: turn off NSS in child process(es)
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.
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?
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.
Assignee: nobody → bsmedberg
This is the most basic thing, which prevents any PSM classes from being initialized.
Attachment #445120 - Flags: review?(honzab.moz)
Adding dep on the channel classifier being run in the chrome process that heavily uses crypto code.
Depends on: 549241
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.
Attachment #445120 - Flags: review?(honzab.moz) → review+
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.
Depends on: 536301
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.
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!
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.
Comment on attachment 464204 [details] [diff] [review] Fix for shared build bustage r+a=me; this is breaking my builds.
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
Assignee: benjamin → nobody
Status: NEW → RESOLVED
Closed: 12 years ago
Component: Libraries → Security: PSM
Product: NSS → Core
QA Contact: libraries → psm
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b4
You need to log in before you can comment on or make changes to this bug.