This patch removes the remaining mozilla-specific dependencies from the
certificate transparency implementation.
Depends on D6845
Differential Revision: https://phabricator.services.mozilla.com/D6846
--HG--
extra : moz-landing-system : lando
In order to make our certificate transparency implementation standalone, we
have to remove mozilla-specific dependencies such as mozilla::Vector.
Depends on D6844
Differential Revision: https://phabricator.services.mozilla.com/D6845
--HG--
extra : moz-landing-system : lando
Put the entire *.firefox.com domain in the list of sites covered by the mozilla services whitelisted roots, which currently include Digicert and Let's Encrypt.
Differential Revision: https://phabricator.services.mozilla.com/D7219
--HG--
extra : moz-landing-system : lando
When navigating to an about: page that doesn't exist (e.g.
"about:somethingthatdoesnotexist"), the docShell will call
nsSecureBrowserUIImpl::OnLocationChange with a request that is null.
Consequently, we can't use that to QueryInterface to a nsISecurityEventSink to
call OnSecurityChange. The previous implementation would use the prior
request's nsISecurityEventSink, which was a bug but luckily this produced the
correct behavior. Since the original docShell the nsSecureBrowserUIImpl was
initialized with is what needs to be notified, we can just QueryInterface that
to an nsISecurityEventSink and call OnSecurityChange directly instead.
Differential Revision: https://phabricator.services.mozilla.com/D6951
--HG--
rename : browser/base/content/test/siteIdentity/browser_tls_handshake_failure.js => browser/base/content/test/siteIdentity/browser_navigation_failures.js
extra : moz-landing-system : lando
This also removes the (afaict, unused) stub implementation from TabParent. The netwerk header
inclusions were necessary because those files included TabParent.h and through it,
nsISecureBrowserUI, but now TabParent.h no longer does that.
Differential Revision: https://phabricator.services.mozilla.com/D6829
--HG--
extra : moz-landing-system : lando
The site identity security indicator machinery treats connections where the TLS
handshake failed as insecure (also referred to as "unknown identity"). Before
bug 1468222, such cases were easily detectable as the SSLStatus field of the
relevant nsITransportSecurityInfo would be null. When we merged nsISSLStatus
into nsITransportSecurityInfo, we didn't take this differentiation into account.
This patch brings back the prior behavior by checking if the securityInfo's
securityState indicates that the handshake failed (i.e. it is
STATE_IS_INSECURE).
Differential Revision: https://phabricator.services.mozilla.com/D6316
--HG--
extra : moz-landing-system : lando
Everything that goes in a PLDHashtable (and its derivatives, like
nsTHashtable) needs to inherit from PLDHashEntryHdr. But through a lack
of enforcement, copy constructors for these derived classes didn't
explicitly invoke the copy constructor for PLDHashEntryHdr (and the
compiler didn't invoke the copy constructor for us). Instead,
PLDHashTable explicitly copied around the bits that the copy constructor
would have.
The current setup has two problems:
1) Derived classes should be using move construction, not copy
construction, since anything that's shuffling hash table keys/entries
around will be using move construction.
2) Derived classes should take responsibility for transferring bits of
superclass state around, and not rely on something else to handle that.
The second point is not a huge problem for PLDHashTable (PLDHashTable
only has to copy PLDHashEntryHdr's bits in a single place), but future
hash table implementations that might move entries around more
aggressively would have to insert compensation code all over the
place. Additionally, if moving entries is implemented via memcpy (which
is quite common), PLDHashTable copying around bits *again* is
inefficient.
Let's fix all these problems in one go, by:
1) Explicitly declaring the set of constructors that PLDHashEntryHdr
implements (and does not implement). In particular, the copy
constructor is deleted, so any derived classes that attempt to make
themselves copyable will be detected at compile time: the compiler
will complain that the superclass type is not copyable.
This change on its own will result in many compiler errors, so...
2) Change any derived classes to implement move constructors instead of
copy constructors. Note that some of these move constructors are,
strictly speaking, unnecessary, since the relevant classes are moved
via memcpy in nsTHashtable and its derivatives.
A previous patch in this bug made the incorrect assumption that we had disabled
the family safety root detection/importing feature by default. In reality, we
enabled it by default in bug 1282871.
In bug 1487258 we moved enterprise root loading to a background thread so as to
not block the main thread. This patch does the same with the family safety
feature.
Differential Revision: https://phabricator.services.mozilla.com/D5484
--HG--
extra : moz-landing-system : lando
I also changed security/certverifier/moz.build a bit while I am here:
* Using '-Xclang' to pass through '-Wall' on clang-cl.
* Now clang-cl will take clang/gcc path because most '-wd****' options have no
effect on clang-cl. '-wd4010' will have an effect, but we already have the
corresponding clang/gcc option ('-Wno-unused-parameter').
--HG--
extra : source : df566a1bd9087cc0bfc03fe19fd9d21bf58f5d9c
Franziskus Kiefer
Brindusan Cristian
Dana Keeler
Julien Vehent
ffxbld
EKR
J.C. Jones
arthur.iakab
Ehsan Akhgari
Noemi Erli
Coroiu Cristina
Boris Zbarsky
shindli
Gijs Kruitbosch
Mark Goodwin
Andrew McCreight
Haik Aftandilian
Dragana Damjanovic
Gurzau Raul
Andreea Pavel
Nathan Froyd
Bogdan Tara
Jed Davis
Masatoshi Kimura