This patch initializes the ulIvBits member of CK_GCM_PARAMS, which is new in PKCS11 v3.
For libprio, we instead define NSS_PKCS11_2_0_COMPAT, which yields the old struct definition.
Differential Revision: https://phabricator.services.mozilla.com/D67740
--HG--
extra : moz-landing-system : lando
Revert setting CK_GCM_PARAMS ulIvBits, as this field won't exist until NSS 3.52.
Depends on D68665
Differential Revision: https://phabricator.services.mozilla.com/D68602
--HG--
extra : moz-landing-system : lando
This patch initializes the ulIvBits member of CK_GCM_PARAMS, which is new in PKCS11 v3.
For libprio, we instead define NSS_PKCS11_2_0_COMPAT, which yields the old struct definition.
Differential Revision: https://phabricator.services.mozilla.com/D67740
--HG--
extra : moz-landing-system : lando
Bug 1034856 added support for DH algorithms to WebCrypto, however the final
specification did not choose to include them, making Firefox the only browser
with support.
Bug 1539578 added telemetry to show usage, and it is extremely low (not
appearing on the graphs), which could be expected as Firefox is the only
supporting browser.
Since DH is an ongoing maintenance burden -- and overall cryptanalysis of DH
is progressing -- let's remove it.
Notice to unship went to dev-platform on 29 March 2019 with no objections. [0]
[0] https://groups.google.com/d/msg/mozilla.dev.platform/Ut3-eQmUdWg/O9w1et1aBgAJ
Differential Revision: https://phabricator.services.mozilla.com/D50865
--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
Since background threads get shut down near `xpcom-shutdown-threads`,
there's no need to have `WebCryptoThreadPool` anymore; we can rely on
the background thread dispatching to fail to dispatch our task as
appropriate.
Differential Revision: https://phabricator.services.mozilla.com/D47006
--HG--
extra : moz-landing-system : lando
Our WebCrypto implementation supports using DH as an algorithm in generateKey,
which is not one of the recognized algorithms in the published specification [0].
We should seek to remove it from Firefox, but before we do, it'd be good to
gather some telemetry on whether it's used at all, even in its' non-standard
form.
[0] https://www.w3.org/TR/WebCryptoAPI/#algorithm-overview
Differential Revision: https://phabricator.services.mozilla.com/D25291
--HG--
extra : moz-landing-system : lando
Our WebCrypto implementation supports using DH as an algorithm in generateKey,
which is not one of the recognized algorithms in the published specification [0].
We should seek to remove it from Firefox, but before we do, it'd be good to
gather some telemetry on whether it's used at all, even in its' non-standard
form.
[0] https://www.w3.org/TR/WebCryptoAPI/#algorithm-overview
Differential Revision: https://phabricator.services.mozilla.com/D25291
--HG--
extra : moz-landing-system : lando
Our WebCrypto implementation supports using DH as an algorithm in generateKey,
which is not one of the recognized algorithms in the published specification [0].
We should seek to remove it from Firefox, but before we do, it'd be good to
gather some telemetry on whether it's used at all, even in its' non-standard
form.
[0] https://www.w3.org/TR/WebCryptoAPI/#algorithm-overview
Differential Revision: https://phabricator.services.mozilla.com/D25291
--HG--
extra : moz-landing-system : lando
As of bug 1417680, the NSS shutdown tracking infrastructure is unnecessary (and
does nothing anyway). This series of changesets removes the remaining pieces in
a way that is hopefully easy to confirm is correct.
MozReview-Commit-ID: 8Y5wpsyNlGc
--HG--
extra : rebase_source : ef6b481510d949e404a4ef5615097d66e566c947
Summary:
After calling mResult.SetLength(mData.Length() + 16) we should check that the
integer addition didn't overflow. It seems at the moment impossible to create
ArrayBuffers of size >= 0x0xfffffff0, however adding a check here doesn't hurt.
mResult.Length() is passed to the PK11 API functions as a maxOut parameter and
/should/ be checked by the softoken crypto algorithm implementations. AES-ECB
and AES-GCM seem to do that correctly.
Reviewers: keeler
Reviewed By: keeler
Subscribers: mcote, ttaubert, jcj, keeler
Bug #: 1413841
Differential Revision: https://phabricator.services.mozilla.com/D188
For the Quatum DOM project, it's better to work in terms of event targets than
threads. This patch converts DOM code to operate on event targets rather than
threads, when possible.
MozReview-Commit-ID: 5FgvpKadUA2
The std::unique_ptr based UniqueX types provide better safety over managing raw
pointers.
MozReview-Commit-ID: EwwOfs6RHqy
--HG--
extra : rebase_source : 7fbfca837c09b641bfffcba854d46b3f79645c0d
enum classes are in general safer than plain enums, and as such should be
preferred.
MozReview-Commit-ID: 1FK89SNhdk4
--HG--
extra : rebase_source : 764c4855026c02d8c9e33ca33637fec54ea5ca31
ScopedPK11Context is based on Scoped.h, which is deprecated in favour of the
standardised UniquePtr.
MozReview-Commit-ID: HE8UY1hOuph
--HG--
extra : transplant_source : 4%BF%81M%09Q-%2A%E6%04%86i%18%1B%3CL%90%88%04%C7
Brindusan Cristian
R. Martinho Fernandes
Simon Giesecke
Kevin Jacobs
J.C. Jones
Nathan Froyd
Henri Sivonen
Bogdan Tara
Ciure Andrei
Sylvestre Ledru
Jon Coppeard
Edouard Oger
Andi-Bogdan Postelnicu
Andrea Marchesini
Sebastian Hengst
Tristan Bourvon
David Keeler
Tim Taubert
Bevis Tseng
Bill McCloskey
Cykesiopka
Ben Kelly
Phil Ringnalda
Tim Taubert
Martin Thomson