Closed Bug 1273687 Opened 8 years ago Closed 4 years ago

Consider whether/when XPConnect sandboxes should be able to see [SecureContext] API

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

RESOLVED FIXED
mozilla74
Tracking Status
firefox74 --- fixed

People

(Reporter: jwatt, Assigned: jkt)

References

Details

Attachments

(1 file)

Follow-up from bug 1177957 comment 23/30.

We should decide what to do about giving XPConnect sandboxes access to [SecureContext] API.
Per email discussion, we should have sandboxes inited with a window inherit its secure context state.  Ones inited with a URL or principal, presumably we would not treat as secure contexts, or we could just base it on that url or principal codebase, right?
Is jwatt going to make the call here?
Flags: needinfo?(jwatt)
Whiteboard: btpp-followup-2016-07-15
The email discussions bz refers to were between bholley, bz and myself. The recommendations from bholley were:

* Xray caller should see the secure APIs if either
  (a) they are system principal, or 
  (b) the Xrayed global sees the APIs.

* We should add a sandbox option, defaulting to false,
  for exposing secure-context APIs.

* IIUC the secure-context-ness can only be deduced from the
  Window, not the Principal, right? Assuming that's the case, I
  agree that the slightly-odd behavior of inheriting
  secure-context-ness when creating a sandbox from a
  Window-as-nsIScriptObjectPrincipal is the way to go.

I agree that we should have sandboxes inited with a window inherit its secure context state. I don't think we can really have sandboxes initialized with a URL or principal be a secure context though, since as bholley notes in that case we don't have enough information to make that call.
Flags: needinfo?(jwatt)
Priority: -- → P2
Whiteboard: btpp-followup-2016-07-15
Priority: P2 → P3
See Also: → 1315029
Jonathan, I'm hitting test failures in bug 1333140 because it turns out that "crypto.subtle" is currently exposed to sandboxes, and even used by at least the Push service. What needs to be done here to move this forward? Do we "simply" need someone to implement what's suggested in comment #3?
Flags: needinfo?(jwatt)
I think so, yes. Maybe reach out to the XPConnect peers to see if one of them can take a look?

https://wiki.mozilla.org/Modules/All#XPConnect
Flags: needinfo?(jwatt) → needinfo?(bzbarsky)
Oops, didn't actually mean to needinfo bz. Probably best to find someone less busy if possible. :)
Flags: needinfo?(bzbarsky)
Fwiw, the plan from comment 3 seems reasonable to me.  We just need someone to implement.
Component: DOM → DOM: Core & HTML

I added the change into the patch for Bug 1333140 however we might want to separate it out here.

It's probably better to factor out the fix for this bug and land it here, not in bug 1333140.

Flags: needinfo?(jkt)
Assignee: nobody → jkt
Status: NEW → ASSIGNED
Pushed by bholley@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/6d51893bde02
Add isSecureContext to xpconnect sandboxes r=bholley
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
Flags: needinfo?(jonathan)
You need to log in before you can comment on or make changes to this bug.