If nsSecureBrowserUIImpl::OnLocationChange receives a
LOCATION_CHANGE_SAME_DOCUMENT notification, it doesn't need to (and in fact
shouldn't) update its security state or notify downstream listeners.
Differential Revision: https://phabricator.services.mozilla.com/D8900
--HG--
extra : moz-landing-system : lando
The desired outcome of this change is that we'll set
-Wl,--version-script based on linker kind and not on the output of
$LINKER -v.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system ld is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system ld doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system ld.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
MinGW suffers somewhat from the opposite problem: the linker "is GNU
ld" (compatible), but the linker checks don't happen at all. We hard-code
for MinGW based on the C compiler instead.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
In reimplementing the OCSP fetching code in bug 1456489, we improperly
translated an assertion that relied on the nullness of a pointer to rely on the
length of a data structure that was populated by reference. It turns out that
this made the assertion invalid because we could return a successful result and
have filled the data structure with zero-length data and it still would be valid
to operate on (the decoding code returns a malformed input result in this case).
To fix this, we can simply remove the assertion. This patch also adds a test to
exercise this case.
Differential Revision: https://phabricator.services.mozilla.com/D8883
--HG--
extra : moz-landing-system : lando
This patch morphs MasterPassword.jsm to OSKeyStore.jsm while keeping the same
API, as an adaptor between the API and the native API exposed as nsIOSKeyStore.idl.
Noted that OS Key Store has the concept of "recovery phrase" that we won't
be adopting here. The recovery phrase, together with our label, allow
the user to re-create the same key in OS key store.
Test case changes are needed because we have started asking for login in
places where we'll only do previously when "master password is enabled".
This also made some "when master password is enabled" tests invalid because
it is always considered enabled.
Some more test changes are needed simply because they previously rely on the
stable order of microtask resolutions (and the stable # of promises for a
specific operation). That has certainly changed with OSKeyStore.
The credit card form autofill is only enabled on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D4498
--HG--
rename : browser/extensions/formautofill/MasterPassword.jsm => browser/extensions/formautofill/OSKeyStore.jsm
rename : browser/extensions/formautofill/test/browser/browser_creditCard_fill_master_password.js => browser/extensions/formautofill/test/browser/browser_creditCard_fill_cancel_login.js
extra : moz-landing-system : lando
This patch introduces the interface with a stub implementation that does
nothing. Follow-up bugs will add platform-specific implementations.
Differential Revision: https://phabricator.services.mozilla.com/D8480
--HG--
extra : moz-landing-system : lando
Before this patch, if a TLS handshake completed but the server then closed the
connection without reading or writing, Firefox would display a connection reset
error page with a secure lock icon. This is misleading and confusing, so in this
patch, nsSecureBrowserUIImpl::OnLocationChange checks if an error page is being
loaded and sets the state to not secure.
Differential Revision: https://phabricator.services.mozilla.com/D8472
--HG--
extra : moz-landing-system : lando
The desired outcome of this change is that we'll set
`-Wl,--version-script` based on linker kind and not on the output of
`$LINKER -v`.
This is a cheap way to address a simple problem that has a complicated
ideal solution. The underlying issue is that in some situations, when
targeting Android, a macOS system `ld` is interrogated to determine if
a cross-compiling linker "is GNU ld" and a particular linker feature
is set in that situation. The macOS system `ld` doesn't pass the "is
GNU ld" test, and the linker feature isn't set; that causes link
failures, even though the actual linker has nothing to do with the
system `ld`.
The ideal solution is to test for linker capabilities dynamically. We
do a lot of that in old-configure.in, and we don't do any of that in
toolchain.configure. Rather than start testing in
toolchain.configure, we hard-code: a cheap solution to the immediate
problem.
Differential Revision: https://phabricator.services.mozilla.com/D8471
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
Only allow access to "com.apple.windowserver.active" when the pref
"security.sandbox.content.mac.disconnect-windowserver" is set to true.
Depends on D6721
Differential Revision: https://phabricator.services.mozilla.com/D7357
--HG--
extra : moz-landing-system : lando
When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
Pass sandbox parameters to content processes on the command
line allowing for early sandbox startup. Limited to Nightly
until confirmed to be stable and ready to ride the trains.
Enable early sandbox startup by default on Nightly and use
pref "security.sandbox.content.mac.earlyinit" to disable
early startup for debugging purposes.
Once early startup is stable, the original sandbox startup
code can be removed.
Depends on D6719
Differential Revision: https://phabricator.services.mozilla.com/D6720
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
Summary:
Resources that aren't secure (e.g. http) can be routed over secure transports
(e.g. http/2 alt-svc, https proxies). For display purposes (the site identity
widget) we don't want to treat these as secure. Bug 1040323 addressed this exact
issue but didn't include tests. Thus, when nsSecureBrowserUIImpl was
reimplemented in bug 832834, this aspect was neglected. This time, there is a
test.
Reviewers: Gijs
Tags: #secure-revision
Bug #: 1495321
Differential Revision: https://phabricator.services.mozilla.com/D7746
--HG--
extra : rebase_source : e17ec47938f41a692b41a7cf65f1d5e4b880e8a7
extra : amend_source : c445c2f5c7eff94be027e238c2f2befc91b3905a
This patch also switches all GlobalSign EV roots to using the CA/Browser Forum
EV policy OID.
Differential Revision: https://phabricator.services.mozilla.com/D8258
--HG--
extra : moz-landing-system : lando
The sandbox blocks GetTempFileName's prior response, causing the system to end up searching a number of (inaccessible) folders to use as a replacement for the temp folder. This patch provides a path to a new folder on the command line for the plugin process. This new temp folder, specific to this plugin process instance, is then communicated to the system via the TEMP/TMP environment variables. This is similar to what is done for the content process but avoids nsDirectoryService, which doesn't exist in plugin processes.
Differential Revision: https://phabricator.services.mozilla.com/D7532
--HG--
extra : moz-landing-system : lando
This patch removes linux64-jsdcov from the available builds on taskcluster along with any hacks used to run it. It also removes any 'coverage' entries that were added to skip tests.
Differential Revision: https://phabricator.services.mozilla.com/D7919
--HG--
extra : moz-landing-system : lando
The symantec distrust should now ride-the-trains in Firefox 64 Beta and Release.
Set security.pki.distrust_ca_policy to 2.
Differential Revision: https://phabricator.services.mozilla.com/D7745
--HG--
extra : moz-landing-system : lando
Only allow access to "com.apple.windowserver.active" when the pref
"security.sandbox.content.mac.disconnect-windowserver" is set to true.
Depends on D6721
Differential Revision: https://phabricator.services.mozilla.com/D7357
--HG--
extra : moz-landing-system : lando
When early initialization of the sandbox is enabled, assert that the sandbox has already been enabled in ContentProcess::Init().
Depends on D6720
Differential Revision: https://phabricator.services.mozilla.com/D6721
--HG--
extra : moz-landing-system : lando
Pass sandbox parameters to content processes on the command
line allowing for early sandbox startup. Limited to Nightly
until confirmed to be stable and ready to ride the trains.
Enable early sandbox startup by default on Nightly and use
pref "security.sandbox.content.mac.earlyinit" to disable
early startup for debugging purposes.
Once early startup is stable, the original sandbox startup
code can be removed.
Depends on D6719
Differential Revision: https://phabricator.services.mozilla.com/D6720
--HG--
extra : moz-landing-system : lando
Simplify the content sandbox policy by removing APP_BINARY_PATH and APP_DIR Mac sandbox parameters and their associated rules in the policy. Keep APP_PATH which is a parent directory of APP_BINARY_PATH and APP_DIR.
Depends on D6717
Differential Revision: https://phabricator.services.mozilla.com/D6719
--HG--
extra : moz-landing-system : lando
When navigating to an about: page that doesn't exist (e.g.
"about:somethingthatdoesnotexist"), the docShell will call
nsSecureBrowserUIImpl::OnLocationChange with a request that is null.
Consequently, we can't use that to QueryInterface to a nsISecurityEventSink to
call OnSecurityChange. The previous implementation would use the prior
request's nsISecurityEventSink, which was a bug but luckily this produced the
correct behavior. Since the original docShell the nsSecureBrowserUIImpl was
initialized with is what needs to be notified, we can just QueryInterface that
to an nsISecurityEventSink and call OnSecurityChange directly instead.
Differential Revision: https://phabricator.services.mozilla.com/D6951
--HG--
rename : browser/base/content/test/siteIdentity/browser_tls_handshake_failure.js => browser/base/content/test/siteIdentity/browser_navigation_failures.js
extra : moz-landing-system : lando
If class A is derived from class B, then an instance of class A can be
converted to B via a static cast, so a slower QI is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D6861
--HG--
extra : moz-landing-system : lando
This patch removes the remaining mozilla-specific dependencies from the
certificate transparency implementation.
Depends on D6845
Differential Revision: https://phabricator.services.mozilla.com/D6846
--HG--
extra : moz-landing-system : lando
In order to make our certificate transparency implementation standalone, we
have to remove mozilla-specific dependencies such as mozilla::Vector.
Depends on D6844
Differential Revision: https://phabricator.services.mozilla.com/D6845
--HG--
extra : moz-landing-system : lando
Put the entire *.firefox.com domain in the list of sites covered by the mozilla services whitelisted roots, which currently include Digicert and Let's Encrypt.
Differential Revision: https://phabricator.services.mozilla.com/D7219
--HG--
extra : moz-landing-system : lando
When navigating to an about: page that doesn't exist (e.g.
"about:somethingthatdoesnotexist"), the docShell will call
nsSecureBrowserUIImpl::OnLocationChange with a request that is null.
Consequently, we can't use that to QueryInterface to a nsISecurityEventSink to
call OnSecurityChange. The previous implementation would use the prior
request's nsISecurityEventSink, which was a bug but luckily this produced the
correct behavior. Since the original docShell the nsSecureBrowserUIImpl was
initialized with is what needs to be notified, we can just QueryInterface that
to an nsISecurityEventSink and call OnSecurityChange directly instead.
Differential Revision: https://phabricator.services.mozilla.com/D6951
--HG--
rename : browser/base/content/test/siteIdentity/browser_tls_handshake_failure.js => browser/base/content/test/siteIdentity/browser_navigation_failures.js
extra : moz-landing-system : lando
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
The site identity security indicator machinery treats connections where the TLS
handshake failed as insecure (also referred to as "unknown identity"). Before
bug 1468222, such cases were easily detectable as the SSLStatus field of the
relevant nsITransportSecurityInfo would be null. When we merged nsISSLStatus
into nsITransportSecurityInfo, we didn't take this differentiation into account.
This patch brings back the prior behavior by checking if the securityInfo's
securityState indicates that the handshake failed (i.e. it is
STATE_IS_INSECURE).
Differential Revision: https://phabricator.services.mozilla.com/D6316
--HG--
extra : moz-landing-system : lando
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
A previous patch in this bug made the incorrect assumption that we had disabled
the family safety root detection/importing feature by default. In reality, we
enabled it by default in bug 1282871.
In bug 1487258 we moved enterprise root loading to a background thread so as to
not block the main thread. This patch does the same with the family safety
feature.
Differential Revision: https://phabricator.services.mozilla.com/D5484
--HG--
extra : moz-landing-system : lando
I also changed security/certverifier/moz.build a bit while I am here:
* Using '-Xclang' to pass through '-Wall' on clang-cl.
* Now clang-cl will take clang/gcc path because most '-wd****' options have no
effect on clang-cl. '-wd4010' will have an effect, but we already have the
corresponding clang/gcc option ('-Wno-unused-parameter').
--HG--
extra : source : df566a1bd9087cc0bfc03fe19fd9d21bf58f5d9c
nsIAssociatedContentSecurity and nsISecurityInfoProvider are unused as of
bug 832834, so this patch removes them.
Differential Revision: https://phabricator.services.mozilla.com/D5693
--HG--
extra : moz-landing-system : lando
Each instance of CERTCertList creates a PLArena with a chunk size of 2048 bytes,
but only needs space for 3 pointers per certificate in the list. The majority of
the time Gecko uses CERTCertList, we'll store ~3 certificates (although in some
cases we do store a few hundred, such as in tests or the certificate manager).
This is fairly inefficient. This patch starts the process of avoiding using
CERTCertList in Gecko by converting nsNSSCertList (i.e. nsIX509CertList) (as
well as nsNSSCertListEnumerator) to use a more efficient data structure to hold
references to certificates long-term. Future follow-up patches could (and
should) update certificate verification APIs in PSM to avoid CERTCertList as
well.
Depends on D5096
Differential Revision: https://phabricator.services.mozilla.com/D5097
--HG--
extra : moz-landing-system : lando
nsIX509CertList.getRawCertList is only used once and doesn't provide
particularly unique functionality (its one use can easily be re-worked in terms
of other APIs). Removing this API will ease refactoring work to avoid holding
long-lived references to CERTCertList instances in nsNSSCertList.
Differential Revision: https://phabricator.services.mozilla.com/D5096
--HG--
extra : moz-landing-system : lando
Background here is that we are disabling a piece of the downgrade protection in TLS 1.3 and we want to turn it on. We don't know if that is safe, so a pref (and an associated experiment) seems prudent. This is that pref.
Differential Revision: https://phabricator.services.mozilla.com/D4629
--HG--
extra : moz-landing-system : lando
Several source files use DLL_PREFIX/DLL_SUFFIX defines, and they all set
them in moz.build using `DEFINES`. This is problematic for the WSL
build because the quoting gets lost somewhere between bash and cl.exe.
We cannot simply set them globally in moz.configure because their
stringified definitions would conflict with the `set_config` of
DLL_PREFIX/DLL_SUFFIX. Therefore, we globally define
MOZ_DLL_PREFIX/MOZ_DLL_SUFFIX and change all define-related uses of
DLL_PREFIX/DLL_SUFFIX to use their MOZ-equivalents instead.
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
Move all fields of nsISSLStatus to nsITransportSecurityProvider
Remove nsISSLStatus interface and definition
Update all code and test references to nsISSLStatus
Maintain ability to read in older version of serialized nsISSLStatus. This
is verified with psm_DeserializeCert gtest.
Differential Revision: https://phabricator.services.mozilla.com/D3704
--HG--
extra : moz-landing-system : lando
As of bug 1346297, we don't collect telemetry for the family safety root
feature. At this point, it makes the most sense to disable the entire feature by
default.
Differential Revision: https://phabricator.services.mozilla.com/D4994
--HG--
extra : moz-landing-system : lando
As of bug 1346297, we don't collect telemetry for the family safety root
feature. At this point, it makes the most sense to disable the entire feature by
default.
Differential Revision: https://phabricator.services.mozilla.com/D4994
--HG--
extra : moz-landing-system : lando
Loading enterprise roots could potentially take a while, so we certainly
shouldn't do it on the main thread at startup. Note that this doesn't address
the case where a user enables the feature while Firefox is running. This isn't
great but since it's an about:config preference rather than a first-class
preference exposed in about:preferences, we can probably get away with it for
now.
Differential Revision: https://phabricator.services.mozilla.com/D4708
--HG--
extra : moz-landing-system : lando
It turns out nsSecureBrowserUIImpl is considerably more complicated than it
needs to be. This patch reimplements it in terms of OnLocationChange only, which
is all it needs to produce the same behavior as before.
Differential Revision: https://phabricator.services.mozilla.com/D3548
--HG--
extra : moz-landing-system : lando
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
extra : intermediate-source : 5152af6ab3e399216ef6db8f060c257b2ffbd330
extra : histedit_source : ef06000344416e0919f536d5720fa979d2d29c66%2C4671676b613dc3e3ec762edf5d72a2ffbe6fca3f
Most of the times when we automatically create nsThread wrappers for threads
that don't already have them, we don't actually need the event targets, since
those threads don't run XPCOM event loops. Aside from wasting memory, actually
creating these event loops can lead to leaks if a thread tries to dispatch a
runnable to the queue which creates a reference cycle with the thread.
Not creating the event queues for threads that don't actually need them helps
avoid those foot guns, and also makes it easier to figure out which treads
actually run XPCOM event loops.
MozReview-Commit-ID: Arck4VQqdne
--HG--
extra : rebase_source : fcf8fa50e748c4b54c3bb1997575d9ffd4cbaae1
extra : source : a03a61d6d724503c3b7c5e31fe32ced1f5d1c219
In bug 1279479 and bug 1316300 we hid some ciphersuites from TLS 1.3
handshakes, assuming we would fall back to TLS 1.2 if the peer needed them.
However, as of bug 1479501, we don't fall back by default, so this just means
we can't negotiate these ciphersuites. This patch un-hides these ciphersuites
from the TLS 1.3 handshake.
Differential Revision: https://phabricator.services.mozilla.com/D4725
--HG--
extra : moz-landing-system : lando
There is a late-breaking EV compatibility concern with cross signatures for EV
certificates:
Firefox's EV handling code always validates EV using the first EV policy OID
expressed in a certificate. For compatibility certificates issued under a cross-
signed root, if the first EV policy OID matches the original Symantec EV policy
OID, then Firefox will attempt to verify that the root CA matches the original
Symantec EV CA -- which it won't, as the root will be one of DigiCert's. Without
a patch, EV treatment will break.
This patch removes all EV policy OIDs for roots mentioned in TrustOverride-
SymantecData.inc, letting the moz::pkix algorithm pick other EV policy OIDs to
validate. I verified that I removed all affected OIDs using the BASH shell
commands:
$ cd security/certverifier
$ grep "CN=" TrustOverride-SymantecData.inc | sed -e 's/.*\(CN=.*\).*/\1/' |
sort | uniq | while read r; do
echo $r; grep "$r" ExtendedValidation.cpp;
done
Reviewers should help me ensure that I did not remove any unexpected EV policy
OIDs.
Differential Revision: https://phabricator.services.mozilla.com/D4709
--HG--
extra : moz-landing-system : lando
This does not change the outward behavior of LossyUTF8ToUTF16(). Both
ToNewUnicode() and CopyASCIItoUTF16() convert from Latin1 to UTF-16.
MozReview-Commit-ID: 8SDgvoGaN4A
Differential Revision: https://phabricator.services.mozilla.com/D4639
--HG--
extra : moz-landing-system : lando
There are surprisingly many of them.
(Plus a couple of unnecessary checks after `new` calls that were nearby.)
--HG--
extra : rebase_source : 47b6d5d7c5c99b1b50b396daf7a3b67abfd74fc1
As initially implemented, nsITLSServerSocket by default enabled the use of the
TLS session cache provided by NSS. However, no consumers of nsITLSServerSocket
actually used it. Because it was an option, though, PSM had to jump through some
hoops to a) make it work in the first place and b) not have NSS panic on
shutdown. Furthermore, it meant increased memory usage for every user of Firefox
(and again, nothing actually used the feature, so this was for naught).
In bug 1479918, we discovered that if PSM shut down before Necko, NSS could
attempt to acquire a lock on the session cache that had been deleted, causing a
shutdown hang. We probably should make it less easy to make this mistake in NSS,
but in the meantime bug 1479918 needs uplifting and this workaround is the
safest, most straight-forward way to achieve this.
Differential Revision: https://phabricator.services.mozilla.com/D3919
--HG--
extra : moz-landing-system : lando
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
In order to allow JS callers to use nsISimpleEnumerator instances with the JS
iteration protocol, we'll need to additional methods to every instance. Since
we currently have a large number of unrelated implementations, it would be
best if they could share the same implementation for the JS portion of the
protocol.
This patch adds a stub nsSimpleEnumerator base class, and updates all existing
implementations to inherit from it. A follow-up will add a new base interface
to this class, and implement the additional functionality required for JS
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D3725
--HG--
extra : rebase_source : ad66d7b266856d5a750c772e4710679fab9434b1
extra : histedit_source : a83ebffbf2f0b191ba7de9007f73def6b9a955b8
Add StartOpenBSDSandbox method calling pledge() syscall,
and use it where we're sandboxing processes.
The pledge subsets are coming from two new prefs:
- security.sandbox.pledge.content for the content process
- security.sandbox.pledge.main for the main process
--HG--
extra : rebase_source : 60da70e2d335755fda6126a6b7de7aad41eebb7e
- Remove the viewCert method from nsICertificateDialogs
- Remove all associated C++ code
- Directly invoke UI window where it was previous called.
- Update tests
MozReview-Commit-ID: 9b62Go0DjE9
Differential Revision: https://phabricator.services.mozilla.com/D3358
--HG--
extra : moz-landing-system : lando
ffxbld
Margareta Eliza Balazs
Dana Keeler
Nick Alexander
Paolo Amadini
Johann Hofmann
Csoregi Natalia
Timothy Guan-tin Chien
Cosmin Sabou
Noemi Erli
Ciure Andrei
Tom Ritter
Narcis Beleuzu
David Parks
shindli
Martin Thomson
Razvan Maries
Bob Owen
Coroiu Cristina
Haik Aftandilian
Gregory Mierzwinski
J.C. Jones
Tiberius Oros
Daniel Varga
Gurzau Raul
Andrew McCreight
Brindusan Cristian
Julien Vehent
trisha
EKR
arthur.iakab
Ehsan Akhgari
Boris Zbarsky
Gijs Kruitbosch
Mark Goodwin
Dragana Damjanovic
Andreea Pavel
Nathan Froyd
Bogdan Tara
Jed Davis
Masatoshi Kimura
Ted Mielczarek
Dipen Patel
Mike Hommey
Jonathan Kingston
Kris Maglione
Kai Engert
Dave Townsend
Henri Sivonen
Alexander Surkov
Jim Mathies
Nicholas Nethercote
Brendan Dahl
Landry Breuil
Robert Helmer
Gian-Carlo Pascutto
Franziskus Kiefer
Dorel Luca