It is the responsibility of code that deals with TypedArrays to apply
the byte offset and byte length. Not doing this caused Unity Web to
crash, as they call getRandomValues with views into their full main
memory. Previously, it would fill their entire memory of about 33.5 MB
with random bytes.
Replicate what we are doing with RSA and parse both the private and
public key when parsing the ASN1.
The only thing that changed in the tests is the error message.
I have divided ANS1 constants by length so that they don't have
trailing zeros that need to be removed.
Also moved OIDs lists to the only place they are used for clarity.
Fixed a couple of WPT tests by adding SECP521r1 to the list of known
curves.
I dug through the code and the WebCryptoAPI spec to figure out the
reason for `... mixed case parameters` WPT tests and figured out that
our implementation was slightly wrong.
By being closer to the spec we can now pass those tests and also remove
a bunch of duplicated code.
Context: https://github.com/LadybirdBrowser/ladybird/pull/2598#discussion_r1859263798
Previously, `ECDH::generate_key` was implemented by storing a
`ByteBuffer` in the `InternalKeyData`. This improves the implementation
by using internal structures of already-parsed data.
Add support for encoding parameters in `wrap_in_private_key_info` and
`wrap_in_subject_public_key_info` as well as turn `Span<int>` into
`Span<int const>`.
By moving `Certificate` to `LibCrypto` it is possible to reuse a bunch
of code from in `LibCrypto` itself. It also moves some constants
and pieces of code to a more appropriate place than `LibTLS`.
This also makes future work on WebCryptoAPI easier.
This is necessary to avoid a circular reference when including
Serializable.h in DOMException.h.
This moves the definition of SerializationRecord, SerializationMemory,
and DeserializationMemory into LibWeb/Forward.h so that Serializable.h
only needs to include LibWeb/Forward.h.
Resulting in a massive rename across almost everywhere! Alongside the
namespace change, we now have the following names:
* JS::NonnullGCPtr -> GC::Ref
* JS::GCPtr -> GC::Ptr
* JS::HeapFunction -> GC::Function
* JS::CellImpl -> GC::Cell
* JS::Handle -> GC::Root
None of the algorithms actually set the `extractable` internal slot in
their implementations, and looking at `SubtleCrypto::import_key()` it
seems likely that a step is missing here.
This gets rid of a couple FIXMEs and allows reusing the logic of
validating this field between different algorithms. While we're here,
expand its logic to match the constraints as outlined in RFC 7517.
The main motivation behind this is to remove JS specifics of the Realm
from the implementation of the Heap.
As a side effect of this change, this is a bit nicer to read than the
previous approach, and in my opinion, also makes it a little more clear
that this method is specific to a JavaScript Realm.
