Move the remaining LibJS primitive string users to UTF-16 views and
strings. Remove the primitive string UTF-8 accessors and byte-string
coercion paths so new callers cannot rely on the old storage model.
Represent BufferSource and ArrayBufferView as ordinary IDL typedefs over
their underlying union types, instead of special casing in the IDL
generator. This allows the union conversion/return machinery handle
these types consistently with other typedefs, which removes buffer
specific paths from the IDL generator.
This necessitates changing the WebIDL::BufferSource and
WebIDL::ArrayBufferView classes as views over these variants. This
replaces the old GC backed BufferableObject wrapper structure and
provide convenience helpers to determine things such as the byte length,
byte offset, backing buffer, and typed-array APIs.
Represent WebIDL C++ types with a single CppType model that tracks
nullability, optional presence, and contained storage.
GC-like values now use GC::Ref/GC::Ptr directly, while containers choose
"plain", "Root", or "Conservative" container types depending on what
they contain. For example, sequence<Element> becomes a RootVector of
GC::Ref values, while sequence<SomeDictionary> becomes a
ConservativeVector only when the dictionary contains GC-like values.
This moves the generated bindings away from wrapping GC values in
GC::Root by default.
This has broad fallout as the types passed to interfaces for GC
objects changes almost fully across the board.
Keep the JsonWebKey dictionary types in line with other dictionary
types in the codebase by putting them in the Crypto namespace
rather than under Web::Bindings.
Previously, the LibWeb bindings generator would output multiple per
interface files like Prototype/Constructor/Namespace/GlobalMixin
depending on the contents of that IDL file.
This complicates the build system as it means that it does not know
what files will be generated without knowledge of the contents of that
IDL file.
Instead, for each IDL file only generate a single Bindings/<IDLFile>.h
and Bindings/<IDLFile>.cpp.
Add a LibCrypto::Authentication::KMAC helper over OpenSSL.
Add keygen/import/export logic into WebCrypto.
Register KMAC128/KMAC256 operations with SubtleCrypto.
Implement AES-OCB AEAD using OpenSSL and expose it through
the WebCrypto API, including key management and AEAD parameters.
Add WPT:
/encrypt_decrypt/aes_ocb.tentative.https.any.html
Implement ChaCha20-Poly1305 AEAD using OpenSSL and expose it through
the WebCrypto API, including key management and AEAD parameters.
Add WPT:
/encrypt_decrypt/chacha20_poly1305.tentative.https.any.worker.html
Introduce a new SHAKE hash wrapper in LibCrypto backed by OpenSSL.
Wire cSHAKE128 and cSHAKE256 into WebCrypto.
Note that cSHAKE with non-empty functionName or customization is
currently rejected due to OpenSSL EVP limitations.
This fixes WPT:
WebCryptoAPI/digest/cshake.tentative.https.any.html
This has quite a lot of fall out. But the majority of it is just type or
UDL substitution, where the changes just fall through to other function
calls.
By changing property key storage to UTF-16, the main affected areas are:
* NativeFunction names must now be UTF-16
* Bytecode identifiers must now be UTF-16
* Module/binding names must now be UTF-16
Add support for AES-KW for key wrapping/unwrapping. Very similar
implementation to other AES modes.
Added generic tests for symmetric import and specific AES-KW ones.
Adds ~400 test passes on WPT. Now we do better than Firefox in
`WebCryptoAPI/wrapKey_unwrapKey`!
This implements the last WebCryptoAPI methods `wrapKey` and `unwrapKey`.
Most of the functionality is already there because they rely on
`encrypt` and `decrypt`. The only test failures are for `AES-GCM` which
is not implemented yet.
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
