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 {, <