Tooltool images are hard to update because we don't provide a script to
generate the image and documentation is often inaccurate.
This patch makes it so we generate the AVD in the android-sdk TL job instead.
Differential Revision: https://phabricator.services.mozilla.com/D119221
The ARM emulator images have very poor support and haven't been updated for a
long time.
Normally x86_64 images need KVM acceleration which is not available on build
machines (see Bug 1545497). We can work around this by starting the emulator
with the command line |--no-accel|.
Differential Revision: https://phabricator.services.mozilla.com/D119223
7.3.0-1 was used because it was the last 7.x that provided the libstdc++6
package. Unfortunately, once libstdc++ is removed from the clang
toolchain, which makes the one from the sysroot used instead, it causes
an ASan issue which goes away when using a more recent version (which the
libstdc++ from clang was: it was 7.5).
So we take the last 7.x that exists, and tweak it so that it generates
the necessary libstdc++6 package.
Differential Revision: https://phabricator.services.mozilla.com/D120012
We use the process handle returned from `CreateProcess` to derive
another handle with more permissions, but the original handle is never
closed. This bug appears to be fairly old: it existed before this code
was converted to use MozPromise.
Currently we provide the original handle to external consumers of the
launch promise; this patch resolves the promise with the privileged
handle instead and closes the original one. (One consumer uses the
handle only to obtain the pid, and the rest don't use it at all, so this
shouldn't change anything.)
As a related cleanup, `ProcessLaunchPromise` is now exclusive (because
it's resolved with resources which are consumed) and no longer declared
in the header file (because it's used only internally).
Differential Revision: https://phabricator.services.mozilla.com/D119820
This patch updates the remembered client authentication decision tab of the
certificate manager to gracefully handle cases where a certificate
corresponding to a remembered decision has been deleted from the user's
certificate store or if it lives on a token that has been removed.
Differential Revision: https://phabricator.services.mozilla.com/D119794
7.3.0-1 was used because it was the last 7.x that provided the libstdc++6
package. Unfortunately, once libstdc++ is removed from the clang
toolchain, which makes the one from the sysroot used instead, it causes
an ASan issue which goes away when using a more recent version (which the
libstdc++ from clang was: it was 7.5).
So we take the last 7.x that exists, and tweak it so that it generates
the necessary libstdc++6 package.
Differential Revision: https://phabricator.services.mozilla.com/D120012
After looking through the methods which have this assertion, I couldn't
find any examples of places where not having a specific "link thread"
sequence would cause any issues. I think these assertions can and should
be removed.
The main change required by this was to remove the `!NS_IsMainThread()`
assertion from the SchedulerGroup listener. Due to how callbacks work,
it would be possible for a vsync message to be detected by a
MessageChannel from the main thread if it was sent before the channel
was bound. I don't believe that this change should cause any issues.
Differential Revision: https://phabricator.services.mozilla.com/D119348
These test various ways of loading documents which will end up with null
principals, and verify that they are loaded with the expected precursor URI.
Depends on D119693
Differential Revision: https://phabricator.services.mozilla.com/D119694
This change stores a generated nsID directly on the LoadInfo, rather
than the full SandboxedLoadingPrincipal. This allows for the sandboxed
principal to be constructed from GetChannelResultPrincipal using the
unsandboxed result principal as a precursor, rather than the loading
principal.
The nsID is reset by HttpChannelBase whenever a non-internal redirect
occurs to reduce the chance of multiple null result principals during a
redirect with the same nsID, but different precursors.
Depends on D119692
Differential Revision: https://phabricator.services.mozilla.com/D119693
This provides a getter which can be used to interact with the precursor
attribute of the null principal.
Depends on D119691
Differential Revision: https://phabricator.services.mozilla.com/D119692
When a navigation redirects, the principalToInherit is reset back to a null
principal for security reasons. This helps prevent a redirect from loading
attacker controlled content with the wrong principal. This patch gives this new
principalToInherit a precursor origin based on the resource which is being
redirected.
One time when this may come up is when an extension redirects a http: request
to a `data:` URI through the request API. Before this change, the load would
complete with a precursorless null principal, but after this change the
precursor refers to the redirected-from URL.
Depends on D119690
Differential Revision: https://phabricator.services.mozilla.com/D119691
If a URI has the URI_INHERITS_SECURITY_CONTEXT flag it will not be given
a content principal by CreateContentPrincipal. This patch changes the
algorithm for creating result principals for network requests such that
the null principal created in this situation has a precursor principal
tracked on it.
Depends on D119689
Differential Revision: https://phabricator.services.mozilla.com/D119690
This method will be the primary way to track the precursor for a null
principal, and will automatically handle tracking precursors in some common
cases.
While sandboxed principals are created with `CreateWithInheritedAttributes`,
they unfortunately currently use the wrong precursor principal, which will be
fixed in a later part.
Depends on D119688
Differential Revision: https://phabricator.services.mozilla.com/D119689
This patch only adds the machinery for tracking a precursor origin to the
principal, and does not actually track the precursor origin in any situations.
That is done in follow-up patches.
Differential Revision: https://phabricator.services.mozilla.com/D119688
This patch disables the update service as if it were disabled by policy
whenever a package identify is present. User interfaces are treated as if
the updater had not been included in the build, because that prevents any of
our usual update UI from being shown, and in particular ensures that we do not
generate messages about an administrator handling updates, as would normally
happen when disabling updates via policy.
The telemetry environment's update.enabled flag is deliberately left alone in
this patch, because the mere fact of using an app package does not really say
anything about whether the user intends to allow automatic updating or not.
Depends on D114427
Differential Revision: https://phabricator.services.mozilla.com/D114886
Followup for bug 1719229 ; some builds have not been tweaked to use the
x86_64-linux-gnu sysroot.
In a few cases, this also use a sysroot for the target part when that
wasn't already the case.
Differential Revision: https://phabricator.services.mozilla.com/D119957
Agi Sferro
Agi Sferro
Cosmin Sabou
Mike Hommey
Jed Davis
Florian Quèze
Dana Keeler
Mitchell Hentges
surajeet310
Nika Layzell
Molly Howell
Sandor Molnar
amy churchwell
Mike Kaply
Eden Chuang
Kershaw Chang
Morgan Reschenberg
Alexandre Lissy
Anuj Gautam
Kajal Sah
Eitan Isaacson
Gavin Lazar Suntop