If a TLS server asks for a client authentication certificate, no dialog asking
the user to select one should be shown until the server's certificate verifies
successfully.
Differential Revision: https://phabricator.services.mozilla.com/D175170
If a TLS server asks for a client authentication certificate, no dialog asking
the user to select one should be shown until the server's certificate verifies
successfully.
Differential Revision: https://phabricator.services.mozilla.com/D175170
The only permission that is set is allowXULXBL, and we don't want
to set that by default, because we don't normally allow XUL in
web content. It can be enabled on an individual test by adding
allow_xul_xbl = true to a test manifest, or by using pushPermissions
within the test.
This also removes the noxul test server, because no XUL is now
the default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D148136
The only permission that is set is allowXULXBL, and we don't want
to set that by default, because we don't normally allow XUL in
web content. It can be enabled on an individual test by adding
allow_xul_xbl = true to a test manifest, or by using pushPermissions
within the test.
This also removes the noxul test server, because no XUL is now
the default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D148136
This uses selection-modification APIs to move up and down by lines in a large text block,
which relies on the block frame's nsILineIterator.
In my local m-c trunk build on macOS, this testcase currently reports times of around 1800ms.
Once the patch in this bug is applied, that drops to around 1300ms.
Differential Revision: https://phabricator.services.mozilla.com/D147577
The expected behavior during a PGO run is that a browser is started and
exited once, and then it is started again on a page that runs various
workloads and once finished, exits.
When workload happens to crash the content process, the browser is left
running indefinitely, until the taskcluster task itself times out. This
leaves us with no possibility of knowing what actually went wrong during
the run, which is about the worst thing that can happen.
With the browser shutting down on its own in case of crash, the harness
can find the minidumps and report the crash, which is more useful.
Differential Revision: https://phabricator.services.mozilla.com/D140678
Inconsistency confuses some of our tools. As part of this, I:
* Updated some docs to point to rust-minidump
* Added a fallback to mozcrash.py to try both versions
* Make mozcrash.py use --brief output when the local mdsw is used
* Remove the renaming hack from build-minidump-stackwalk.sh
This isn't as simple as a sed because we still have breakpad in tree
for minidump-analyzer. I did my best to replace the right strings.
Differential Revision: https://phabricator.services.mozilla.com/D138971
* the certificates were regenerated using `./mach generate-test-certs`
* the build/pgo/certs/ changes were made using
`./mach python build/pgo/genpgocert.py`
* the zip files in security/manager/ssl/tests/unit/test_signed_apps/ were
updated per the directions in the corresponding moz.build file
* security/manager/ssl/tests/unit/test_cert_override_read.js needed manual
updating
Differential Revision: https://phabricator.services.mozilla.com/D135283
Having 3 regular domains to test fission scenarios will help migrating to https-first for DevTools mochitests.
example.org and example.com are both available in http and https, but example.net is only available in http for now.
This patch was created by adding https://example.net to build/pgo/server-locations.txt and then running `./mach python build/pgo/genpgocert.py`
Differential Revision: https://phabricator.services.mozilla.com/D127922
Chrome has removed 3DES completely[0], but we're still seeing some uses of it
in telemetry. Our assumption is that this is either due to old devices that
can't be upgraded, and hence probably use TLS 1.0, or servers that bafflingly
choose 3DES when there are other, better, ciphersuites in common.
This patch allows 3DES to only be enabled when deprecated versions of TLS are
enabled. This should protect users against the latter case (where 3DES is
unnecessary) while allowing them to use it in the former case (where it may be
necessary).
NB: The only 3DES ciphersuite gecko makes possible to enable is
TLS_RSA_WITH_3DES_EDE_CBC_SHA. This patch also changes the preference
corresponding to this ciphersuite from "security.ssl3.rsa_des_ede3_sha" to
"security.ssl3.deprecated.rsa_des_ede3_sha".
[0] https://www.chromestatus.com/feature/6678134168485888
Differential Revision: https://phabricator.services.mozilla.com/D121797
This patch updates ssltunnel to have a configuration where it only uses a 3DES
ciphersuite, rather than RC4 ciphersuites. This has to be done in stages
because otherwise android tests will fail, because their hostutils doesn't
actually use what's in-tree, and has to be updated separately.
Differential Revision: https://phabricator.services.mozilla.com/D122393
Chrome has removed 3DES completely[0], but we're still seeing some uses of it
in telemetry. Our assumption is that this is either due to old devices that
can't be upgraded, and hence probably use TLS 1.0, or servers that bafflingly
choose 3DES when there are other, better, ciphersuites in common.
This patch allows 3DES to only be enabled when deprecated versions of TLS are
enabled. This should protect users against the latter case (where 3DES is
unnecessary) while allowing them to use it in the former case (where it may be
necessary).
NB: The only 3DES ciphersuite gecko makes possible to enable is
TLS_RSA_WITH_3DES_EDE_CBC_SHA. This patch also changes the preference
corresponding to this ciphersuite from "security.ssl3.rsa_des_ede3_sha" to
"security.ssl3.deprecated.rsa_des_ede3_sha".
[0] https://www.chromestatus.com/feature/6678134168485888
Differential Revision: https://phabricator.services.mozilla.com/D121797
