Andreas Kling
96ddccd961
LibWeb: Implement the importKey algorithm for X448
2024-11-25 17:16:51 +01:00
Andreas Kling
4a734226aa
LibWeb: Implement the exportKey algorithm for X448
2024-11-25 17:16:51 +01:00
Andreas Kling
5a8b0a2610
LibWeb: Implement the generateKey algorithm for X448
2024-11-25 17:16:51 +01:00
Andreas Kling
7b678d3e1f
LibWeb: Throw TypeError if WebCrypto algorithm doesn't have "name" field
2024-11-24 23:28:23 +01:00
Andreas Kling
fe98cbcae1
LibWeb: Don't copy HashMaps so dang much in WebCrypto
2024-11-24 23:28:23 +01:00
Andreas Kling
ed7b1caba2
LibWeb: Implement the exportKey algorithm for Ed25519
2024-11-24 23:28:23 +01:00
Andreas Kling
4d25369f29
LibWeb: Implement the importKey algorithm for Ed25519
2024-11-24 23:28:23 +01:00
devgianlu
009f328308
LibWeb: Implement ECDH.generateKey
2024-11-21 11:45:22 +01:00
Jelle Raaijmakers
b895a135d5
LibWeb: Update spec implementation for SubtleCrypto.deriveKey()
...
Our spec issue got resolved, including a bonus fix!
See: https://github.com/w3c/webcrypto/pull/384
2024-11-15 18:51:15 +01:00
Shannon Booth
f87041bf3a
LibGC+Everywhere: Factor out a LibGC from LibJS
...
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
2024-11-15 14:49:20 +01:00
Jelle Raaijmakers
f7993495bd
LibWeb: Set key extractability in SubtleCrypto::derive_key()
...
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.
2024-11-15 12:32:04 +01:00
Jelle Raaijmakers
f8c853712e
LibWeb: Add some missing spec links to Crypto
2024-11-15 12:32:04 +01:00
Jelle Raaijmakers
329cd946ac
LibWeb: Implement Web Crypto HMAC algorithm
CI / Lagom (false, FUZZ, ubuntu-24.04, Linux, Clang) (push) Waiting to run
CI / Lagom (false, NO_FUZZ, macos-15, macOS, Clang) (push) Waiting to run
CI / Lagom (false, NO_FUZZ, ubuntu-24.04, Linux, GNU) (push) Waiting to run
CI / Lagom (true, NO_FUZZ, ubuntu-24.04, Linux, Clang) (push) Waiting to run
Package the js repl as a binary artifact / build-and-package (macos-14, macOS, macOS-universal2) (push) Waiting to run
Package the js repl as a binary artifact / build-and-package (ubuntu-24.04, Linux, Linux-x86_64) (push) Waiting to run
Run test262 and test-wasm / run_and_update_results (push) Waiting to run
Lint Code / lint (push) Waiting to run
Push notes / build (push) Waiting to run
2024-11-14 11:52:18 +01:00
Shannon Booth
9b79a686eb
LibJS+LibWeb: Use realm.create<T> instead of heap.allocate<T>
...
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.
2024-11-13 16:51:44 -05:00
Timothy Flynn
93712b24bf
Everywhere: Hoist the Libraries folder to the top-level
2024-11-10 12:50:45 +01:00
