1457017 - Should network.disable.ipc.security be still set to true?

Status: RESOLVED DUPLICATE of bug 1306801

(Core :: Networking, enhancement)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I stumbled across the network.disable.ipc.security pref and was wondering why this was set to true in release. I noticed a comment which said that we should have changed this after 1125916 was fixed, so Im just filing this out of precaution. I suspect this check might be something related to check that network requests come from an appId which corresponds to the child process but Im really not sure. AppId was mainly (exclusively?) a b2g concept so maybe it doesn't matter that this pref is still set to true. But just wanted to be sure, hence this bug.


https://searchfox.org/mozilla-central/source/devtools/client/webide/content/runtimedetails.js#133

Comment 1

[Jim Mathies [:jimm]]

Sounds like something the netwerking team introduced that can be removed. Jason, can you help here?

Comment 2

[Jason Duell]

Valentin: I poked around a little at this--enabling the the pref basically toggles UsingNeckoIPCSecurity(), which we use in UDPSocketParent::Init() and a whole bunch of MissingRequiredTabChild() checks in our e10s child channels.

I don't actually know if the security checks in these codepaths are still up to date, post bug 1125916.  I'm guessing Valentin knows this as well as anyone in necko--feel free to ask seceng folks if needed.

Comment 3

[Valentin Gosu [:valentin] (he/him)]

I believe we can dupe this to bug 1306801.
I don't think there's much reason for keeping this around.
We may want to keep a check similar to UsingNeckoIPCSecurity(), but given that it's currently disabled, it probably doesn't help that much.