This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
This will allow the errors reported via this method to show up in the web console as needed.
Differential Revision: https://phabricator.services.mozilla.com/D56386
--HG--
extra : moz-landing-system : lando
I falsely did set the ReportError flag to aRes instead of false, which was flooding the console.
Differential Revision: https://phabricator.services.mozilla.com/D56379
--HG--
extra : moz-landing-system : lando
CheckMayLoadAndReport takes a window ID. This allows us to report
errors from it to the web console as needed. Most consumers know statically
whether they want reporting or not, so there's no reason to force the ones that
don't to provide window ids.
Differential Revision: https://phabricator.services.mozilla.com/D56388
--HG--
extra : moz-landing-system : lando
This will allow the errors reported via this method to show up in the web console as needed.
Differential Revision: https://phabricator.services.mozilla.com/D56386
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
This is generally pretty straightforward, and rewrites nearly all calls. It
skips the ones that it can detect using frame script globals like
`sendAsyncMessage`, though.
Differential Revision: https://phabricator.services.mozilla.com/D53740
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
`CreateSuffix` is irreversible by `PopulateFromSuffix` because it uses a multi-to-one mapping.
Since only ':' will happen in a IPv6 format, we can make it a 1-to-1 mapping so that the `firstPartyDomain` is consistent after `CreateSuffix` and `PopulateFromSuffix`.
Differential Revision: https://phabricator.services.mozilla.com/D47910
--HG--
extra : moz-landing-system : lando
This change means fewer temporary objects, particularly `nsCString` objects.
Depends on D55688
Differential Revision: https://phabricator.services.mozilla.com/D55689
--HG--
extra : moz-landing-system : lando
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
XPConnect calls this method during shutdown after the pointer to the
singleton nsScriptSecurityManager has been cleared, so it is actually
calling it with a null |this|. Nobody noticed this because it isn't
actually using |this|. This patch turns it into a static method to
make the sanitizers happy.
Differential Revision: https://phabricator.services.mozilla.com/D54846
--HG--
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
This way we get the correct values for start-up prefs in the parent process.
Differential Revision: https://phabricator.services.mozilla.com/D51061
--HG--
extra : moz-landing-system : lando
Lots of these callbacks have a non-`void*` final parameter, which UBSAN
complains about. This commit changes them to have a `void*` parameter.
This requires undoing the machinery added in the first two commits of bug
1473631: `TypePrefChangeFunc` and `PREF_CHANGE_METHOD`. The resulting code is
simpler (which is good) and more boilerplate-y (which is bad) but avoids the
undefined behaviour (which is good).
Differential Revision: https://phabricator.services.mozilla.com/D50901
--HG--
extra : moz-landing-system : lando
This patch adds support for including content_scripts CSP in the extensions
manifest, along with all interfaces necessary to access the CSP value. This does not
implement actual use of the CSP for content scripts.
Differential Revision: https://phabricator.services.mozilla.com/D46824
--HG--
extra : moz-landing-system : lando
In this patch, we add the propagation of the first party domain through
the tabContext while creating OOP browsers. In the window.open() case,
we will propagate the first party domain from the opener's browser parent.
And in the frame case, we will propagate it from the manager of the
browserBridgeParent of the OOP frame.
Differential Revision: https://phabricator.services.mozilla.com/D49886
--HG--
extra : moz-landing-system : lando
`CreateSuffix` is irreversible by `PopulateFromSuffix` because it uses a multi-to-one mapping.
Since only ':' will happen in a IPv6 format, we can make it a 1-to-1 mapping so that the `firstPartyDomain` is consistent after `CreateSuffix` and `PopulateFromSuffix`.
Differential Revision: https://phabricator.services.mozilla.com/D47910
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
Add a new FIXUP_FLAG_PRIVATE_CONTEXT to nsIURIFixup, make it use the default
private search engine when it's set.
Update consumers to pass the new flag when necessary.
Differential Revision: https://phabricator.services.mozilla.com/D48741
--HG--
extra : moz-landing-system : lando
This patch does several things. Because Workers aren't on the main thread,
many of the things done are in the name of off main thread access.
1) Changes a parameter in IsEvalAllowed from a nsIPrincipal to a bool.
We only used the principal to determined if it was the System Principal.
Principals aren't thread safe and can only be accessed on Main Thread, so
if we passed a Principal in, we would be in error. Instead only pass in
the bool which - for workers - comes from a thread-safe location.
2) Separates out the Telemetry Event Recording and sending a message to the
console into a new function nsContentSecurityUtils::NotifyEvalUsage. (And
creates a runnable that calls it.)
We do this because we will need to only call this method on the main thread.
Telemetry Event Recording has only ever been called on the Main Thread.
While I possibly-successfully cut it over to happen Off Main Thread (OMT)
by porting preferences to StaticPrefs, I don't know if there were other
threading assumptions in the Telemetry Code. So it would be much safer to
just continue recording Event Telemetry on the main thread.
Sending a message to the console requires calling GetStringBundleService()
which requires main thread. I didn't investigate if this could be made
thread-safe, I just threw it onto the main thread too.
If, in IsEvalAllowed, we are on the main thread - we call NotifyEvalUsage
directly. If we are not, we create a runnable which will then call
NotifyEvalUsage for us on the main thread.
3) Ports allow_eval_with_system_principal and allow_eval_in_parent_process
from bools to RelaxedAtomicBool - because we now check these prefs OMT.
4) In RuntimeService.cpp, adds the call to IsEvalAllowed.
5) Add resource://gre/modules/workers/require.js to the allowlist of eval
usage. This was the script that identified this gap in the first place.
It uses eval (twice) for structural reasons (scope and line number
massaging.) The contents of the eval are the result of a request to a
uri (which may be internal, like resource://). The whole point of this
is to implement a CommonJS require() api.
This usage of eval is safe because the only way an attacker can inject
into it is by either controlling the response of the uri request or
controlling (or appending to) the argument. If they can do that, they
are able to inject script into Firefox even if we cut this usage of eval
over to some other type of safe(r) script loader.
Bug 1584564 tracks making sure calls to require.js are safe.
6) Adds cld-worker.js to the allowlist. Bug 1584605 is for refactoring that
eval usage, which is decidedly non-trivial.
7) Does _not_ enforce the eval restrictions for workers. While I've gotten
try to be green and not throw up any instances of eval-usage by workers,
it is much safer to deploy this is Telemetry-only mode for Workers for
a little bit to see if anything pops up from the Nightly population.
Bug 1584602 is for enforcing the checks.
Differential Revision: https://phabricator.services.mozilla.com/D47480
--HG--
extra : moz-landing-system : lando
Finally, here we add the virtual method isSystemOrAddonPrincipal to the
JSPrincipal object.
We also add it to nsJSPrincipal (where it has an easy implementation), and
to carry classes that are used by JS tests and the shell.
Differential Revision: https://phabricator.services.mozilla.com/D47477
--HG--
extra : moz-landing-system : lando
We log to MOZ_LOG, report an error to the console, send telemetry, and in debug builds - crash
Differential Revision: https://phabricator.services.mozilla.com/D45055
--HG--
extra : moz-landing-system : lando
This will permit implementation of JSPrincipals::write().
Differential Revision: https://phabricator.services.mozilla.com/D44604
--HG--
rename : dom/worklet/WorkletPrincipal.cpp => dom/worklet/WorkletPrincipals.cpp
rename : dom/worklet/WorkletPrincipal.h => dom/worklet/WorkletPrincipals.h
extra : moz-landing-system : lando
We now correctly handle the following cases:
- Thunderbird
- the Browser Toolbox/Console
- Two safe and common idioms
- when general.config.filename is set and userChromeJS does shenanigans
We also change the function to only crash in Debug mode, and for Release channels
we report diagnostic information in a way that does not reveal user data.
Differential Revision: https://phabricator.services.mozilla.com/D39557
--HG--
extra : moz-landing-system : lando
If an XPIDL interface has a method or attribute that is [notxpcom],
then it is implicitly treated as [builtinclass], even if it is not
marked as such. For clarity, this patch goes through and marks every
place that relies on this behavior (aside from some test code).
Differential Revision: https://phabricator.services.mozilla.com/D30714
--HG--
extra : moz-landing-system : lando
The attributes for an interface should be on the line right before the
interface.
Interface attributes should be separated by spaces.
Clean up some trailing whitespace in widget/.
Differential Revision: https://phabricator.services.mozilla.com/D28234
--HG--
extra : moz-landing-system : lando
This excludes dom/, otherwise the file size is too large for phabricator to handle.
This is an autogenerated commit to handle scripts loading mochitest harness files, in
the simple case where the script src is on the same line as the tag.
This was generated with https://bug1544322.bmoattachments.org/attachment.cgi?id=9058170
using the `--part 2` argument.
Differential Revision: https://phabricator.services.mozilla.com/D27456
--HG--
extra : moz-landing-system : lando
Right now the firstPartyDomain is not set when host is in the public suffix list. The patch fixes it by setting firstPartyDomain to eTLD.getPublicSuffix in these cases.
Differential Revision: https://phabricator.services.mozilla.com/D26767
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
1. Adding a new attribute chromeContext in ConsoleEvent
2. Adding a new boolean attribute isFromChromeContext in nsIConsoleMessage
3. Sending IsFromChromeContext to the parent process
Differential Revision: https://phabricator.services.mozilla.com/D23330
--HG--
extra : moz-landing-system : lando
Replaced instances of callers in both C++ and JS files to query the state from the principal directly.
Differential Revision: https://phabricator.services.mozilla.com/D22532
--HG--
extra : moz-landing-system : lando
This is needed to maintain full feature parity with the existing
nsIPrincipal serializer while switching to using the PrincipalInfo-based
one.
Depends on D14434
Differential Revision: https://phabricator.services.mozilla.com/D20854
--HG--
extra : moz-landing-system : lando
This is needed to maintain full feature parity with the existing
nsIPrincipal serializer while switching to using the PrincipalInfo-based
one.
Depends on D20853
Differential Revision: https://phabricator.services.mozilla.com/D20854
--HG--
extra : moz-landing-system : lando
This patch in the series ensures that the order of operations in
recursive invocations of CommonTestPermission() remains consistent
compared to before the patch series, even though it is not strictly
needed for the performance improvements that the series focuses on.
The core idea behind CommonPrepareToTestPermission() now is to do the checks
that do not depend on the host name being tested, and for
CommonTestPermissionInternal() itself to focus on the rest of the checks,
that is looking up our hashtable entry based on the host name being tested,
and everything else that's needed from that point on.
Depends on D20235
Differential Revision: https://phabricator.services.mozilla.com/D20236
--HG--
extra : moz-landing-system : lando
The change to test_clonewrapper.xul is because in the new setup we've already
tried handing an object across origins via chrome code, so it has a cached
(opaque) wrapper. When we set document.domain and pass the same object again,
we end up picking up the cached wrapper when we try to wrap across the
compartment boundary, so don't grant access when perhaps we should...
This does lead to a possible spec violation in the following situation:
1) Two documents (A, B) start out same-site but different-origin.
2) Privileged code (system or extension) puts a reference to an object from
site A into site B. This object gets an opaque CCW.
3) Both sites set document.domain to become same-effective-script-origin and
then site B goes through the site A Window and the object graph hanging off it
and gets to the object involved. It gets an opaque CCW when it should have a
transparent CCW.
We could fix this if we kept recomputing wrappers on document.domain change and
just fixed the compartment filter used by the recomputation. But this seems
like a pretty rare situation, and not one web sites can get into without an
assist from a somewhat buggy extension or system code, so let's see whether we
can just live with it and remove the recomputation.
Differential Revision: https://phabricator.services.mozilla.com/D18032
--HG--
extra : moz-landing-system : lando
Prevent web_accessible_resources resources loading in private contexts when extension does not have permission.
Differential Revision: https://phabricator.services.mozilla.com/D17138
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
nsIPrincipal::GetURI returns NS_OK for all implementations. Make it
infallible so we can clean up status checks in C++ code that uses principals.
Differential Revision: https://phabricator.services.mozilla.com/D16145
--HG--
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
Because it release-asserts the compartment has a single realm.
I also renamed JS_GetCompartmentPrincipals to JS_DeprecatedGetCompartmentPrincipals
to discourage people from using it.
Differential Revision: https://phabricator.services.mozilla.com/D14252
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is needed because UA Widget cannot load resources from chrome://mozapps.
Depends on D11701
Differential Revision: https://phabricator.services.mozilla.com/D11702
--HG--
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/osx/global/plugins/pluginHelp-16.png
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/windows/global/plugins/pluginHelp-16.png
extra : moz-landing-system : lando
This is needed because UA Widget cannot load resources from chrome://mozapps.
Depends on D11701
Differential Revision: https://phabricator.services.mozilla.com/D11702
--HG--
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/osx/global/plugins/pluginHelp-16.png
rename : toolkit/themes/osx/mozapps/plugins/pluginHelp-16.png => toolkit/themes/windows/global/plugins/pluginHelp-16.png
extra : moz-landing-system : lando
Creates the nsDocShellLoadState object, which is basically
nsDocShellLoadInfo plus a few extra fields to make it usable as a
single argument to nsDocShell::LoadURI (and eventually
nsDocShell::InternalLoad).
Subframe history handling is a huge logic block in
nsDocShell::LoadURI, which is only used on history loads. This patch
also extracts the logic out into its own function to make the body of
LoadURI clearer.
This patch adds a MOZ_DIAGNOSTIC_ASSERT for assuring the OAs
are matching when the targetOrigin is "*" for the postMessage().
But it ignores the FPD in OA since the FPDs are possible to be
different.
We also add a new pref 'privacy.firstparty.isolate.block_post_message'
for allowing blocking postMessage across different FPDs.
Differential Revision: https://phabricator.services.mozilla.com/D8521
--HG--
extra : moz-landing-system : lando