Base64 encoding is done to top-level principal and the sub-principals
of expanded principals. Getting rid of the Base64 encoding entirely
also lets us use jsoncpp consider expanded principals to be entirely
serialized as JSON.
Differential Revision: https://phabricator.services.mozilla.com/D166783
Base64 encoding is done to top-level principal and the sub-principals
of expanded principals. Getting rid of the Base64 encoding entirely
also lets us use jsoncpp consider expanded principals to be entirely
serialized as JSON.
Differential Revision: https://phabricator.services.mozilla.com/D166783
This patch only makes the very basics of nsIPrincipal manipulation threadsafe,
such as reference counting, and some trivial methods. The more complex methods
will be made threadsafe in following parts.
Differential Revision: https://phabricator.services.mozilla.com/D163032
This patch is meant to be a proposed short run fix to prevent ApplyAddonContentScriptCSP
from leaking the ExpandedPrincipal and nsCSPContext instance because they keep a reference
to each other.
This patch prevent that leak by creating a clone of the ExpandedPrincipal and then use
that cloned instance in the call to nsCSPContext::SetRequestContextWithPrincipal.
Once Bug 1548468 will move the CSP off the ExpandedPrincipal class, cloning the expanded
principal to prevent that leak should not be necessary anymore.
Differential Revision: https://phabricator.services.mozilla.com/D132144
This is a step towards separating the mutable state on principals from const
state which can be made threadsafe. The remaining mutable fields will either
need to be moved off of nsIPrincipal or made threadsafe to destroy (e.g. using
nsMainThreadPtrHandle) and stored behind a mutex.
Serialization is handled for most types using a separate Deserializer class,
like how it was handled with `nsIURI` mutators. SystemPrincipal wasn't changed
as the `Read` method is a no-op for that class.
Differential Revision: https://phabricator.services.mozilla.com/D115092
This is necessary to remove the Init methods from principals, allowing
immutable fields to be marked as const and clearly separated from mutable
fields to improve threadsafety.
Differential Revision: https://phabricator.services.mozilla.com/D115091
By declaring the individual enum types to fit in a `uint8_t`, and
rearranging the templated `KeyValT` struct, we can pack `KeyValT`
to save a word of storage.
Differential Revision: https://phabricator.services.mozilla.com/D55687
--HG--
extra : moz-landing-system : lando
This will let us answer the following questions (in a performant way):
1) What's the compartment's origin? Necessary to implement compartment-per-origin.
2) What's the origin's site? Necessary for the new Wrap() algorithm.
3) Has any realm in the compartment set document.domain? Necessary for the new Wrap() algorithm.
Differential Revision: https://phabricator.services.mozilla.com/D5423
--HG--
extra : moz-landing-system : lando
We need to side-step existing cross-origin checks in Performance Timing code
when the caller is a web extension content script that otherwise has permission
to access the cross-origin resource.
MozReview-Commit-ID: 8IgtqZgPWgY
--HG--
extra : rebase_source : e8152c5d8ab32096d1ff7f97311c1b43b57c3694
The logic for choosing the principal here was originally written before
loadInfo had a separate principalToInherit field, and we needed to specify it
via the triggeringPrincipal instead. At that point, we had to choose a
component principal with permission to load the URI at the start of the
request.
However, now that we have a separate field for the principal to inherit, it's
only needed after access checks have passed and we know that we have a URI
which inherits a principal. In that case, the current logic causes us to
always inherit the first principal in the whitelist (which is the page
principal) for URIs (such as data: URIs) that always inherit, where we really
want to inherit the last (which is the extension principal).
MozReview-Commit-ID: EPoUNuOCwrH
--HG--
extra : rebase_source : 535083e3dd4598ac4e8ea187d27d61ac2ac48476
There are several ways that expanded principals can be used as triggering
principals for requests. While that works fine for security checks, it also
sometimes causes them to be inherited, and used as result principals in
contexts where expanded principals aren't allowed.
This patch changes our inheritance behavior so that expanded principals are
downgraded to the most appropriate constituent principal when they would
otherwise be inherited.
The logic for choosing the most appropriate principal is a bit suspect, and
may eventually need to be changed to always select the last whitelist
principal, but I chose it to preserve the current principal downgrade behavior
used by XMLHttpRequest for the time being.
MozReview-Commit-ID: 9fvAKr2e2fa
--HG--
extra : rebase_source : c30df1b3851c11fed5a1d6a7fb158cec14933182
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
The extension policy services uses atoms internally for permission names, so
using them directly rather than strings is considerably cheaper.
MozReview-Commit-ID: Io8EuOXHKVy
--HG--
extra : rebase_source : 577b4bdf7f899729e4cf92961a8e9e25bf886a72
Tooru Fujisawa
Andreas Farre
Cristina Horotan
Nika Layzell
Luca Greco
Andrea Marchesini
Nathan Froyd
Jonathan Kingston
Christoph Kerschbaumer
Sylvestre Ledru
Boris Zbarsky
Jan de Mooij
Tomislav Jovanovic
Kris Maglione
Nicholas Nethercote
Ryan VanderMeulen
Sebastian Hengst