Firefox essentially does not support running NSS in FIPS mode any longer. This
has always been the case on Android from what I can tell and it has been the
case on OS X since at least version 34 (see bug 1047584). It became the case on
Windows as of version 53 (see bug 1295937). Unfortunately, before this patch,
if a user attempted to run an affected version of Firefox using a profile
directory containing an NSS database collection that had FIPS enabled, NSS
initialization would fail and fall back to running in no DB mode, which had the
side-effect of making any saved passwords and certificates unavailable. This
patch attempts to detect and work around this failure mode by moving the
PKCS#11 module DB (which is where the FIPS bit is set) to a backup location and
basically running with a fresh, non-FIPS module DB. This allows Firefox to
initialize NSS with the preexisting key and certificate databases available.
MozReview-Commit-ID: 1E4u1ngZyRv
--HG--
rename : security/manager/ssl/tests/unit/test_sdr_preexisting.js => security/manager/ssl/tests/unit/test_broken_fips.js
rename : security/manager/ssl/tests/unit/test_sdr_preexisting/key3.db => security/manager/ssl/tests/unit/test_broken_fips/key3.db
extra : rebase_source : 887f457e998d6e57c6536573fbe3cb10547fe154
There appear to be no in-tree users of this function and it references
"b2g." I'm pretty sure it is dead code.
MozReview-Commit-ID: EHHRQ2iqQoP
--HG--
extra : rebase_source : ec136063dc5e4243232fce5289a8f47bd925b481
We shouldn't be running any Firefox OS automation.
MozReview-Commit-ID: 4ea9SL7jill
--HG--
extra : rebase_source : 6d5c457d14d9d2b2b4abda47a2b3bfa1fa745d36
We shouldn't be running any automation related to Firefox OS. We should
be able to delete these files.
MozReview-Commit-ID: SY5f0GD9NQ
--HG--
extra : rebase_source : 3b7b5b28bc5da554ad9082c1c3115b3ab8de2e0a
These were the last occurrences of "gaia" in the mozharness directory.
MozReview-Commit-ID: 8ACEw1rMoUS
--HG--
extra : rebase_source : b5d98c9166d75a83f5303ee0faa34484b6f998d3
This is functionally equivalent since one variant of the
PushStackingContext was already delegating to the other (in
DisplayListBuilder).
MozReview-Commit-ID: 8PfMm3bHeSZ
This class is a RAII class that can be used to push a stacking context
with properties from a WebRenderLayer. It can also then be used to
convert rects in the layer coordinate system to be relative to the
stacking context, which is what we want for passing to WR.
MozReview-Commit-ID: 1WVrfRYqLqc
As we are often converting from LayoutDevicePixel to LayerPixel types
in WebRenderDisplayItem code, I added a convenience overload of
RelativeToParent that takes a LayoutDeviceRect and returns a LayerRect,
even though this is a potential footgun if abused.
MozReview-Commit-ID: DABAWdOBsbV
This extracts a strongly-typed ClipRect() function from GetWrClipRect.
GetWrClipRect is left as a weakly-typed wrapper for existing call sites,
and also does the necessary reference point conversions.
MozReview-Commit-ID: EuyzYIYLR6S
This moves the bulk of the meaningful work done by GetWrRelBounds into
strongly-typed helper functions. GetWrRelBounds is left as a wrapper so
call sites don't need to be updated yet. Note also that the
strongly-typed functions do not do any conversions from one reference
point from another (e.g. by calling the RelativeToXXX functions).
MozReview-Commit-ID: B3nPbOJOf9o
Since the longString object has an actor property which can change from test to test,
replace it with its value in the existing packet.
MozReview-Commit-ID: CzxX203TdEU
--HG--
extra : rebase_source : df89c67ba760ab48b3e5e9e38378314e06dfc0fb
The test doesn't verify that the exceptions are reported to the browser console,
but I manually checked that they are. Adding a test for that part could be
pretty annoying.
David Keeler
Wes Kocher
Gregory Szorc
Kartikaya Gupta
sotaro
Joel Maher
Christoph Kerschbaumer
ffxbld
Dragana Damjanovic
Emilio Cobos Álvarez
nchevobbe
Tobias Schneider
JerryShih
Andrea Marchesini
Boris Zbarsky
Geoff Brown