Provides an optional resolver mechanism for Firefox that allows running
together with or instead of the native resolver.
TRR offers resolving of host names using a dedicated DNS-over-HTTPS server
(HTTPS is required, HTTP/2 is preferable).
DNS-over-HTTPS (DOH) allows DNS resolves with enhanced privacy, secure
transfers and improved performance.
To keep the failure rate at a minimum, the TRR system manages a dynamic
persistent blacklist for host names that can't be resolved with DOH but works
with the native resolver. Blacklisted entries will not be retried over DOH for
a couple of days. "localhost" and names in the ".local" TLD will not be
resolved via DOH.
TRR is preffed OFF by default and you need to set a URI for an available DOH
server to be able to use it. Since the URI for DOH is set with a name itself,
it may have to use the native resolver for bootstrapping. (Optionally, the
user can set the IP address of the DOH server in a pref to avoid the required
initial native resolve.)
When TRR starts up, it will first verify that it works by checking a
"confirmation" domain name. This confirmation domain is a pref by default set
to "example.com". TRR will also by default await the captive-portal detection
to raise its green flag before getting activated.
All prefs for TRR are under the "network.trr" hierarchy.
The DNS-over-HTTPS spec: https://tools.ietf.org/html/draft-ietf-doh-dns-over-https-03
MozReview-Commit-ID: GuuU6vjTjlm
--HG--
extra : rebase_source : 53fcca757334090ac05fec540ef29d109d5ceed3
Guest sessions on Ubuntu (and maybe other distributions that use
LightDM?) apply an AppArmor policy that allows CLONE_NEWUSER but doesn't
allow using any of the capabilities it grants, or even configuring the
new user namespace.
This patch causes those environments to be detected as not supporting
unprivileged user namespaces, because for all practical purposes they
don't.
MozReview-Commit-ID: HVkoBakRwaA
--HG--
extra : rebase_source : 4028eff177de30acc58f7f0c32989265dfcad9fd
This warning is triggered by the use of alignas() in js/public/RootingAPI.h.
Now that GeckoProfiler.h includes RootingAPI.h, this warning is encountered
when building security/certverifier because GeckoProfiler.h is already being
included transitively, through this inclusion path:
CertVerifier.cpp -> CertVerifier.h -> Telemetry.h -> StartupTimeline.h -> GeckoProfiler.h
However, this explanation is not entirely satisfactory, because there seems to
be an existing inclusion path for RootingAPI.h already:
CertVerifier.cpp -> CertVerifier.h -> BasePrincipal.h -> OriginAttributes.h
-> ChromeUtils.h -> ChromeUtilsBinding.h -> RootingAPI.h
So I'm not quite sure why this problem is only starting to happen now.
MozReview-Commit-ID: AFuXpTjdPsi
--HG--
extra : rebase_source : 60f74c8655d15fbc6acbf0ce8a2f208e198e231e
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
This fixes a mistake in bug 1401062: the termination signal was omitted,
so it's 0, and if it isn't exactly SIGCHLD, then a tracer/debugger will
receive PTRACE_EVENT_CLONE rather than PTRACE_EVENT_FORK. This causes
GDB to see the child process as a thread instead of a separate process,
and it becomes very confused after the process calls execve().
MozReview-Commit-ID: Baf2RFHVWRU
--HG--
extra : rebase_source : 50839967fc766bb9db123fe1af99a88495f8421b
This commit reworks PublicKeyPinningService::ChainHasValidPins and
PublicKeyPinningService::EvalChain to use nsNSSCertList directly. It also
updates nsSiteSecurityService::ProcessPKPHeader. This will be made more
efficient in Bug 1406854, where the call to VerifySSLServerCert gets replaced
with one to GetSucceededCertChain. (Such a change is premeature now because
before Bug 731478 lands this would lead to a session resumption regression
causing pins to not be set properly, which is triggered repeatedly in the
xpcshell tests.)
MozReview-Commit-ID: 1l186n1lXLH
--HG--
extra : rebase_source : 88e40bbf41b324ece762abfa84a758380102e199
extra : histedit_source : addcddf253c2901a25b29f65046908f52df61345
This change is to use the higher-level structure nsNSSCertList when checking
IsChainValid so that we can use the more powerful (and tested) methods of that
object instead of the ad-hoc iterators.
This will also permit the Symantec Distrust code in Bug 1434300 to use these
methods, which keeps the code the same from the earlier Bug 1409259.
MozReview-Commit-ID: B5KmDa1JLE
--HG--
extra : rebase_source : 397d3ef7189eb6f81a1ceaf920464d9e842a8981
extra : histedit_source : 26b22257cb5fcc3389630dd0a1aba24095c46158
This adds another utility method to nsNSSCertList to perform CERT_LIST_TAIL on
the underlying certificate list and return the last entry -- e.g., the root.
This is a convenience method to let other parts of the certificate verifier
continue to work with the higher-level nsNSSCertificate objects instead of
having to convert them.
MozReview-Commit-ID: EEi9L5Iepc6
--HG--
extra : rebase_source : 2836767a7186f65debf338f8d1f2a981636ed29b
extra : histedit_source : 5b87ec6c522ac1b84d91052e21184f3c03d9ea52
This is part of the work to remove XUL overlays. All of these overlays are
used only once and do not need to be in their own overlay files.
MozReview-Commit-ID: Ecwq2UN52o9
--HG--
extra : rebase_source : 5a9692c7d9965940847ae1d488d1b94a2abf66c7
This replaces the globals for whether socket calls (and ipc(2) calls, but
we never used that) have real arguments with a parameter, which in hindsight
should have been done in bug 1273852, which is when we started handling
both socketcall(2) and separate socket calls in the same policy. This
allows handling the two cases differently.
MozReview-Commit-ID: 1pfckmCpJlW
--HG--
extra : rebase_source : 4b8459f01e8748fea95cbcb6eeb689f01417ca5b
There are a few things that use SysV IPC, which we discovered the last
time we tried to do this, which need to be accomodated:
1. The ALSA dmix plugin; if the build has ALSA support (off by default)
and if audio remoting is disabled, SysV IPC is allowed.
2. ATI/AMD's old proprietary graphics driver (fglrx), which is obsolete
and doesn't support newer hardware, but still has users; if it's
detected, SysV IPC is allowed.
3. Graphics libraries trying to use the MIT-SHM extension; this is
already turned off for other reasons (see bug 1271100), but that shim
seems to not load early enough in some cases, so it's copied into
libmozsandbox, which is preloaded before anything else in LD_PRELOAD.
Also, msgget is now blocked in all cases; the only case it was known
to be used involved ESET antivirus, which is now handled specially
(bug 1362601). In any case, the seccomp-bpf policy has never allowed
actually *using* message queues, so creating them is not very useful.
MozReview-Commit-ID: 5bOOQcXFd9U
--HG--
extra : rebase_source : ea79c0a7e31f58f056be15b551c57dde974dfae2
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
ca.pem is used to sign certificates that are either verified at time 2016-08-25
or time "now", with the earliest such certificate having a notBefore of
2015-07-24. As such, ca.pem.certspec needs to have a notBefore time that is no
later than 2015-07-24, but be valid for a reasonably long time.
Therefore, ca.pem.certspec is changed so the cert has a notBefore of 2015-01-01,
and is valid for 20 years.
ee-int-nsSGC-*.pem are verified at time 2016-08-25, and so need to be valid
at that time.
Therefore, the ee-int-nsSGC-*.pem.certspec files are changed so the
corresponding certs have validity periods that match their intermediates.
MozReview-Commit-ID: duOnvGGcuD
--HG--
extra : amend_source : 307c9d95b617560a547081ff8924d05ec2f2d2a8
For this, I've uncommented the relevant bits in moz.build files, then:
./mach build security/manager
for dir in $(rg GeneratedTestCertificate | grep security | cut -d : -f 1); do
cp obj-x86_64-pc-linux-gnu/$(dirname $dir)/*.pem $(dirname $dir);
done
And same with GeneratedTestKey / *.key
MozReview-Commit-ID: C2bkSo6YYCU
--HG--
extra : amend_source : b59d21b695544a1a4b6c45ba9c00c40f8ceb0f1a