Revert bug 1570581 by removing the AppleEvent entitlement from our hardened runtime configuration for both production and development.
Now that native messaging helpers are started 'disclaimed' with a new attribution chain, the entitlement is not needed.
Differential Revision: https://phabricator.services.mozilla.com/D48029
--HG--
extra : moz-landing-system : lando
On macOS, launch native messaging helper apps with a new "Transparency, Consent, and Control" (TCC) attribution chain using the undocumented disclaim posix_spawn attribute.
Differential Revision: https://phabricator.services.mozilla.com/D48028
--HG--
extra : moz-landing-system : lando
Our policy is to allow video document to autoplay only when it's in the top-level window. However, `docshell::GetInProcessSameTypeRootTreeItem()` is not compatible with Fission so that we are not able to get the top-level document if we are in the remote process.
Therefore, we should use `BrowsingContext` instead, to check if the video document is in the top-level context.
Differential Revision: https://phabricator.services.mozilla.com/D51216
--HG--
extra : moz-landing-system : lando
Using `SpecialPowers.spawn` to replace `ContentTask.spawn` and to make sure we run `ok` and `is` under the right window scope.
Differential Revision: https://phabricator.services.mozilla.com/D51039
--HG--
extra : moz-landing-system : lando
The responsiveness was stored with periodic stack samples.
Since bug 1581049, periodic stack samples are now contained within a single
"modern" `CompactStack` entry.
When a thread is sleeping, `CompactStack`s are simply copied verbatim, including
the responsiveness, which doesn't make sense because since we're sleeping so the
responsiveness should still increase.
To avoid duplicating the responsiveness, it is now stored as a separate buffer
entry `UnresponsiveDurationMs` before the `CompactStack`; this replaces the
legacy entry `Responsiveness` that was stored at the end of the stack.
Differential Revision: https://phabricator.services.mozilla.com/D51554
--HG--
extra : moz-landing-system : lando
The pretty-printer expects to find the value of the `NON_NATIVE` flag in
`js::Class`, which doesn't exist any more. That flag is now a static const
member of `JSClass`.
Differential Revision: https://phabricator.services.mozilla.com/D51489
--HG--
extra : moz-landing-system : lando
nsCOMArray currently casts a function that takes two `void` pointers into a
function that takes two `nsISupports` pointers. UBSAN doesn't like this.
This commit introduces an extra level of casting machinery. As a result, each
comparison done while sorting goes through an extra level, to get from `(T*,
T*)` comparisons to `(nsISupports*, nsISupports*)` comparisons to `(void*,
void*)` comparisons, as required by `NS_QuickSort()`. It's a bit annoying but I
can't see how else to solve this within the constraint imposed by the existing
`nsCOMArray_base`/`nsCOMArray` split.
Differential Revision: https://phabricator.services.mozilla.com/D51223
--HG--
extra : moz-landing-system : lando
Recent Qualcom drivers are exhibiting the same issues as seen in previous
versions when decoding video. Notably:
- Crashes.
- Green frames.
This patch expands our black list to avoid these problems.
Differential Revision: https://phabricator.services.mozilla.com/D51722
--HG--
extra : moz-landing-system : lando
Most of these tests relied on assumptions that were broken by the new content
event utils (timing, being in a ContentTask, etc).
Differential Revision: https://phabricator.services.mozilla.com/D51442
--HG--
extra : moz-landing-system : lando
This also changes BrowserTestUtils.addContentEventListener to use browsing
contexts to track added listeners and their associated targets.
Differential Revision: https://phabricator.services.mozilla.com/D51441
--HG--
extra : moz-landing-system : lando
Various BrowserTestUtils.waitForContentEvent call sites expect to see an event
on a browser element that was open before the call was made. For this reason,
each of the browsers need to also have a ContentEventListener actor.
Differential Revision: https://phabricator.services.mozilla.com/D51440
--HG--
extra : moz-landing-system : lando
BrowserTestUtils.waitForErrorPage may resolve slightly earlier than it did
before, so we may arrive at an about:neterror page that hasn't been completely
initialized. We should only dispatch the AboutNetErrorLoad event when we're done
making changes to the page.
Differential Revision: https://phabricator.services.mozilla.com/D51439
--HG--
extra : moz-landing-system : lando
This uses `Document.hasValidTransientUserGestureActivation` to expose
gesture for use in the `onLoadRequest()` delegate method in GeckoView,
allowing apps to know if a load was initiated by a user.
Differential Revision: https://phabricator.services.mozilla.com/D51729
--HG--
extra : moz-landing-system : lando
These were unveiled by the coming patch.
We didn't use to call run_next_test for the links that expected no visits before
bug 1591717.
Differential Revision: https://phabricator.services.mozilla.com/D51620
--HG--
extra : moz-landing-system : lando
The previous code tried to do it, but it did it wrongly, as the overflow clip
comes from the parent, not the child.
Thus when we change a style that influences it, we weren't invalidating the
SIMPLE_DISPLAY_LIST bit, and such.
Make the reftest that caught this fail more reliable.
Differential Revision: https://phabricator.services.mozilla.com/D51805
--HG--
extra : moz-landing-system : lando
This fixes css/css-contain/contain-paint-{002,012,024}.html when not using the
fast path (i.e., with the following patch).
Also invert the check in IsStackingContext as IsFrameOfType is a virtual method,
and IsContain* is just a bitflag.
Differential Revision: https://phabricator.services.mozilla.com/D51804
--HG--
extra : moz-landing-system : lando
This change updates the home page to webxr.today for Firefox Realty on Desktop. Further, since WebVR is not supported yet, this change includes a way to disable WebVR specifically for FxR windows without impacting Desktop Fx.
Differential Revision: https://phabricator.services.mozilla.com/D51426
--HG--
extra : moz-landing-system : lando
2019-11-04 Marcus Burghardt <mburghardt@mozilla.com>
* lib/pk11wrap/pk11cert.c:
Bug 1590495 - Crash in PK11_MakeCertFromHandle->pk11_fastCert. r=jcj
Fixed controls to avoid crashes caused by slots possibly without a
token in pk11_fastCert. Also, improved arguments controls in
PK11_MakeCertFromHandle.
[dc9552c2aa77] [tip]
2019-11-01 Franziskus Kiefer <franziskuskiefer@gmail.com>
* gtests/pk11_gtest/manifest.mn,
gtests/pk11_gtest/pk11_des_unittest.cc,
gtests/pk11_gtest/pk11_gtest.gyp, lib/softoken/pkcs11c.c:
Bug 1591742 - check des iv length and add test for it, r=jcj,kjacobs
Summary: Let's make sure the DES IV has the length we expect it to
have.
Bug #: 1591742
[35857ae98190]
2019-11-01 Dana Keeler <dkeeler@mozilla.com>
* gtests/mozpkix_gtest/pkixcheck_CheckKeyUsage_tests.cpp, lib/mozpkix
/test-lib/pkixtestnss.cpp, tests/gtests/gtests.sh:
Bug 1588567 - enable mozilla::pkix gtests in NSS r=jcj
[27a29997f598]
2019-11-01 Deian Stefan <deian@cs.ucsd.edu>
* lib/softoken/pkcs11c.c:
Bug 1591315 - Update NSC_Decrypt length in constant time r=kjacobs
Update NSC_Decrypt length in constant time
[7f578a829b29]
2019-11-01 Kai Engert <kaie@kuix.de>
* automation/taskcluster/graph/src/queue.js:
Bug 1562671 - Limit Master Password KDF iterations for NSS
continuous integration tests. r=mt
[c8b490583b86]
* lib/softoken/lgglue.c, lib/softoken/sftkdb.c, lib/softoken/sftkdb.h,
lib/softoken/sftkdbti.h, lib/softoken/sftkpwd.c:
Bug 1562671 - Add environment variables to control Master Password
KDF iteration count. Disable iteration count for legacy DBM storage
by default. r=rrelyea
[ced91a705aa3]
2019-11-01 Bob Relyea <rrelyea@redhat.com>
* lib/softoken/legacydb/keydb.c, lib/softoken/lgglue.c,
lib/softoken/pkcs11.c, lib/softoken/sftkdb.c, lib/softoken/sftkdb.h,
lib/softoken/sftkdbti.h, lib/softoken/sftkpwd.c:
Bug 1562671 - Support higher iteration count for Master Password
KDF. Bob Relyea's base patch. Requires the follow-up patch. r=kaie
[6619bb43d746]
2019-10-28 Martin Thomson <mt@lowentropy.net>
* coreconf/Linux.mk, coreconf/WIN32.mk, coreconf/command.mk,
coreconf/config.gypi, coreconf/rules.mk, lib/freebl/aes-armv8.c,
lib/freebl/aes-x86.c, lib/freebl/config.mk, lib/freebl/freebl.gyp,
lib/freebl/intel-aes.h, lib/freebl/intel-gcm-wrap.c,
lib/freebl/rijndael.c, lib/freebl/rijndael.h, lib/ssl/config.mk,
lib/ssl/ssl.gyp:
Bug 1590972 - Use -std=c99 for all C code, r=jcj
This switches to using -std=c99 for compiling all C code.
Previously, we only enabled this option for lib/freebl and lib/ssl.
For Linux, this means we need to define _DEFAULT_SOURCE to access
some of the functions we use. On glibc 2.12 (our oldest supported
version), we also need to define _BSD_SOURCE to access these
functions.
The only tricky part is dealing with partial C99 implementation in
gcc 4.4. From what I've seen, the only problem is that - in that
mode - it doesn't support nesting of unnamed fields:
https://gcc.gnu.org/onlinedocs/gcc-4.4.7/gcc/Unnamed-Fields.html
This also switches from -std=c++0x to -std=c++11 as the 0x variant,
though identical in meaning, is deprecated.
[dbba7db4b79d]
2019-10-30 Giulio Benetti <giulio.benetti@benettiengineering.com>
* lib/freebl/aes-armv8.c, lib/freebl/rijndael.c:
Bug 1590676 - Fix build if arm doesn't support NEON r=kjacobs
At the moment NSS assumes that ARM supports NEON extension but this
is not true and leads to build failure on ARM without NEON
extension. Add check to assure USE_HW_AES is not defined if ARM
without NEON extension is used.
[58f2471ace3b]
2019-10-30 Martin Thomson <mt@lowentropy.net>
* gtests/ssl_gtest/tls_agent.cc:
Bug 1575411 - Disable EMS for tests, a=bustage
[6e5f69781137]
2019-10-29 J.C. Jones <jjones@mozilla.com>
* gtests/ssl_gtest/tls_esni_unittest.cc:
Bug 1590970 - Fix clang-format from
e7956ee3ba1b6d05e3175bbcd795583fde867720 r=me
[d1e43cb9f227]
2019-10-29 Giulio Benetti <giulio.benetti@benettiengineering.com>
* lib/ssl/tls13esni.c:
Bug 1590678 - Remove -Wmaybe-uninitialized warning in tls13esni.c
r=jcj
[df5e9021809a]
2019-10-29 Martin Thomson <martin.thomson@gmail.com>
* lib/ssl/ssl.h, lib/ssl/sslsock.c:
Bug 1575411 - Enable extended master secret by default,
r=jcj,kjacobs
See the bug for discussion about the implications of this.
[d1c68498610d]
2019-10-29 Martin Thomson <mt@lowentropy.net>
* gtests/ssl_gtest/tls_esni_unittest.cc, lib/ssl/sslexp.h:
Bug 1590970 - Stop using time() for ESNI tests, r=kjacobs
Summary: The ESNI tests were using time() rather than PR_Now(), so
they slipped the net when I went looking for bad time functions. Now
they do the right thing again.
What we were probably seeing in the intermittents was the case where
we set the time for most of the SSL functions to PR_Now(), and that
was just before a second rollover. Then, when time() was called, it
returned t+1 so the ESNI keys that were being generated in the ESNI
tests were given a notBefore time that was in the future relative to
the time being given to the TLS stack. Had the ESNI keys generation
been given time() - 1 for notBefore, as I have done here, this would
never have turned up.
Reviewers: kjacobs
Tags: #secure-revision
Bug #: 1590970
[e7956ee3ba1b]
Differential Revision: https://phabricator.services.mozilla.com/D51858
--HG--
extra : moz-landing-system : lando
`TaskQueue` wraps an `nsIEventTarget` to provide "one runnable at a
time" execution policies regardless of the underlying implementation of
the wrapped `nsIEventTarget` (e.g. a thread pool). `TaskQueue` also
provides a `nsISerialEventTarget` wrapper, `EventTargetWrapper`, around
itself (!) for consumers who want to continue to provide a more
XPCOM-ish API.
One would think that dispatching tasks to `EventTargetWrapper` with a
given set of flags would pass that set of flags through, unchanged, to
the underlying event target of the wrapped `TaskQueue`.
This pass-through is not the case. `TaskQueue` supports a "tail
dispatch" mode of operation that is somewhat underdocumented. Roughly,
tail dispatch to a `TaskQueue` says (with several other conditions) that
dispatched tasks are held separately and not passed through to the
underlying event target. If a given `TaskQueue` supports tail dispatch
and the dispatcher also supports tail dispatch, any tasks dispatched to
said `TaskQueue` are silently converted to tail dispatched tasks. Since
tail dispatched tasks can't meaningfully have flags associated with
them, the current implementation simply drops any passed flags on the floor.
These flags, however, might be meaningful, and we should attempt to
honor them in the cases we're not doing tail dispatch. (And when we are
doing tail dispatch, we can verify that the requested flags are not
asking for peculiar things.)
Differential Revision: https://phabricator.services.mozilla.com/D51702
--HG--
extra : moz-landing-system : lando
The current API name is bad: we want it to be read "some background
thread", but it could just as easily be read "a singular background
thread", which would lead people to assume that for:
```
NS_DispatchToBackgroundThread(...);
NS_DispatchToBackgroundThread(...);
```
the dispatched tasks will necessarily run in the order they are
dispatched, which is not the case.
Let's try to head off that interpretation by renaming this function.
Differential Revision: https://phabricator.services.mozilla.com/D51703
--HG--
extra : moz-landing-system : lando
