Open nss in-memory-only on the socket process

RESOLVED INVALID

Status

()

enhancement
P1
normal
RESOLVED INVALID
5 months ago
5 months ago

People

(Reporter: dragana, Assigned: mayhemer)

Tracking

(Blocks 1 bug)

59 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-triaged])

Comment hidden (empty)
(Assignee)

Updated

5 months ago
(Assignee)

Updated

5 months ago
No longer blocks: socket-proc
(Assignee)

Updated

5 months ago
Assignee: nobody → honzab.moz
Status: NEW → ASSIGNED
Priority: -- → P1
Whiteboard: [necko-triaged]
(Assignee)

Comment 1

5 months ago
Looks like we don't need to do much here.  There is already a code to initialize NSS in content process at [1], the same function will very well work on the socket process as well.

Byron, can you please confirm the code at [1] will work for you on the socket process and that there is nothing more needed?  Note that with what has landed so far on larch we are not initializing nss on the socket process at all (I believe.)

If confirmed, we will likely only have to add `|| XRE_IsSocketProcess()` to the condition at 431 along with bug 1484751 landing.

[1] https://searchfox.org/mozilla-central/rev/876022232b15425bb9efde189caf747823b39567/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp#436 / https://hg.mozilla.org/projects/larch/annotate/11819394462e/media/webrtc/signaling/src/peerconnection/PeerConnectionImpl.cpp#l436
Flags: needinfo?(docfaraday)
I think that should be fine. We use NSS_NoDB_Init() in a bunch of unit-tests, and those work fine. I do not think we currently have a test-case that uses a real WebrtcProxyChannel in an STS that is initted like this, so that remains a question.
Flags: needinfo?(docfaraday)
(Reporter)

Comment 3

5 months ago
Let's do this as a part of WebRTC work. I will close this bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → INVALID
(Assignee)

Comment 4

5 months ago
(In reply to Dragana Damjanovic [:dragana] from comment #3)
> Let's do this as a part of WebRTC work. I will close this bug.

According Byron's comment 2 this more seems like a WORKSFORME.  Except the "a real WebrtcProxyChannel in an STS" thing which I don't fully understand and wanted to make it more clear with Byron.

Can you elaborate what exactly you mean with "Let's do this as a part of WebRTC work"?  That's what this bug was filed for and blocked socket-proc-webrtc.

Thanks.
(Reporter)

Comment 5

5 months ago
I want to separate what is to be done before WebRTC work and after WebRTC start moving to the socket process. At some point InitNSSInContent in PeerConnectionImpl.cpp needs to be change to turn on nss on the socket process as well (that is why it is not WORKSFORME), but to do that we need to run the webRTC code on the socket process. So this is work that needs to be done during WebRTC move to the socket process and I will leave this to the WebRTC group.

About WebrtcProxyChannel, you can ask anyway.

I believe that turning on nss needs to be part of concrete WebRTC work, because they know at which point it needs to be turned on.
(Assignee)

Comment 6

5 months ago
Got it.  Thanks.
You need to log in before you can comment on or make changes to this bug.