Wallet openssl ed25519 #26770

supermassive · 2024-11-27T07:08:46Z

Resolves brave/brave-browser#42579
SecReview: https://github.com/brave/reviews/issues/1808

Drop dependency on ed25519-dalek-bip32 and some related crates.
Use ED25519_* functions from OpenSSL as a replacement.
Implement SLIP-10 child key derivation scheme.
To be done in a follow up PR: support Cardano derivation scheme(SLIP-23) based on this PR

Submitter Checklist:

I confirm that no security/privacy review is needed and no other type of reviews are needed, or that I have requested them
There is a ticket for my issue
Used Github auto-closing keywords in the PR description above
Wrote a good PR/commit description
Squashed any review feedback or "fixup" commits before merge, so that history is a record of what happened in the repo, not your PR
Added appropriate labels (QA/Yes or QA/No; release-notes/include or release-notes/exclude; OS/...) to the associated issue
Checked the PR locally:
- npm run test -- brave_browser_tests, npm run test -- brave_unit_tests wiki
- npm run presubmit wiki, npm run gn_check, npm run tslint
Ran git rebase master (if needed)

Reviewer Checklist:

A security review is not needed, or a link to one is included in the PR description
New files have MPL-2.0 license header
Adequate test coverage exists to prevent regressions
Major classes, functions and non-trivial code blocks are well-commented
Changes in component dependencies are properly reflected in gn
Code follows the style guide
Test plan is specified in PR before merging

After-merge Checklist:

The associated issue milestone is set to the smallest version that the
changes has landed on
All relevant documentation has been updated, for instance:

Test Plan:

kdenhartog

Some comments for you as I'm starting to review.

From a quick look at BoringSSL I can't see any reason that there would be a difference between it and dalek such that key recovery attacks would occur, but I want to dig in a bit more and will do that as you get a chance to go through these changes.

components/brave_wallet/browser/internal/hd_key_ed25519.cc

third_party/rust/chromium_crates_io/vendor/ed25519-dalek-2.1.1/Cargo.toml

components/brave_wallet/browser/internal/hd_key_ed25519_unittest.cc

components/brave_wallet/browser/solana_keyring_unittest.cc

components/brave_wallet/common/hash_utils_unittest.cc

kdenhartog · 2024-12-11T02:21:37Z

components/brave_wallet/browser/internal/hd_key.cc

-    return nullptr;
-  }
-  DCHECK(out_len == kSHA512Length);
+  auto hmac = HmacSha512(base::byte_span_from_cstring(kMasterSecret), seed);


Should this be typed as a SecureVector still?

Not sure why it was a secure vector before. seed and mnemonic are not 'secure' in this way but have same or higher level of importance.

It makes sense to clear private keys from memory when wallet is locked after browser being idle for some time. But I don't see a consistent approach when/what we should clear at active runtime.

Looks like this is when it was introduced.

It seems like we may have just missed some of these as refactors occurred since the change. Let's keep this as a SecureVector in here and then can do a follow-up issue to be more consistent about using SecureVector once ZCash work is finished up. In general, my preference is that if it's a secret we don't want left in memory after the wallet is locked then we should set it as a SecureVector. The one area where this might be a bit tricky is going to be zcash with their various key structures hence wanting to wait until that's finished.

kdenhartog · 2024-12-11T02:23:50Z

components/brave_wallet/browser/internal/hd_key_ed25519.cc

+std::unique_ptr<HDKeyEd25519> HDKeyEd25519::GenerateFromSeedAndPath(
+    base::span<const uint8_t> seed,
+    std::string_view hd_path) {
+  auto hd_key = base::WrapUnique(


I think this should be a SecureVector type too?

Made it's fields to be SecureByteArray

components/brave_wallet/browser/internal/hd_key_ed25519.cc

kdenhartog · 2024-12-11T02:26:04Z

components/brave_wallet/browser/internal/hd_key_ed25519.cc

-  if (path_ != kMasterNode) {
-    VLOG(0) << "must derive only from master key";
+// static
+std::unique_ptr<HDKeyEd25519> HDKeyEd25519::GenerateFromSeedAndPath(


Todo for myself: check to make sure that BoringSSL behaves as expected with this compared to Dalek-Ed25519 to avoid key recovery attacks

kdenhartog · 2024-12-13T02:19:11Z

things still blocking this are:

Keep SecureVector memory matching what we had previously (@supermassive and I discussed over DM) to keep it simple.
Remove the Check usage
Todo for myself to review boringSSL usage with this SLIP-10 implementation

cdesouza-chromium · 2024-12-19T19:51:56Z

I’m planning to review this change in the coming days, however I would like to ask beforehand for this PR to be broken apart into digestible smaller PRs. The GitHub UI is not the most friendly for code review of changes this size. If the high file count is due to deps being added/removed, this could be submitted separately.

bridiver · 2024-12-19T20:34:46Z

components/brave_wallet/browser/internal/hd_key_ed25519_unittest.cc

-      base::ToLowerASCII(base::HexEncode(master_key->GetPublicKeyBytes())),
-      "a4b2856bfec510abab89753fac1ac0e1112364e7d250545963f135f2a33188ed");
+  auto master_key = HDKeyEd25519::GenerateFromSeedAndPath(bytes, "m");
+  EXPECT_EQ(HexEncodeLower(master_key->GetPrivateKeyAsSpan()),


I think it would be better if you didn't make this change to use HexEncodeLower in this PR. It makes it harder to see what is still the still the same vs changed vs added. Not critical, but it would be an easier read and you could follow-up to change the tests

rolled back

bridiver · 2024-12-19T20:36:48Z

components/brave_wallet/browser/internal/hd_key_utils.h

+// derivations in terms of DeriveHardened/DeriveNormal calls.
+std::optional<std::vector<uint32_t>> ParseFullHDPath(std::string_view path);
+
+class ScopedSecureZeroSpan {


the filename should be scoped_secure_zero_span to match the class name

I guess there is also ParseFullHDPath above so this should go in a separate file. We shouldn't use *utils.h as a kind of dumping ground for random related class and methods. Classes should generally go in their own files and it's better to make the "utils" more specific to the actual function vs generic "hd_key"

actually this doesn't seem related to the change in implementation and has some other issues related to base::span storage

removed to be redone in a follow up

bridiver · 2024-12-19T20:45:05Z

components/brave_wallet/browser/internal/hd_key_utils.h

+namespace brave_wallet {
+
+namespace internal {
+void SecureZeroBuffer(base::span<uint8_t> data);


Seems like this would make more sense as a static private method on ScopedSecureZeroSpan and use friend for SecureByteArray and tests?

actually this method is just calling crypto::internal::SecureZeroBuffer so we don't need it at all

That was to avoid exposing crypto/process_bound_string.h through header.
Now removed

bridiver · 2024-12-19T20:47:21Z

components/brave_wallet/browser/internal/hd_key_utils.h

+// TODO(apaymyshev): We most likely do not need this parsing as at runtime all
+// parsing is done from hardcoded strings. Worth implementing account roots
+// derivations in terms of DeriveHardened/DeriveNormal calls.
+std::optional<std::vector<uint32_t>> ParseFullHDPath(std::string_view path);


ParseBIP32FullDerivationPath? https://google.github.io/styleguide/cppguide.html#General_Naming_Rules

does this also possibly make more sense as part of some existing class? If not that's ok, but maybe this should be bip32_utils or something after moving ScopedSecureZeroSpan to its own class.

Brandon-T · 2024-12-19T20:52:05Z

components/brave_wallet/common/hash_utils.h

@@ -17,9 +17,11 @@ namespace brave_wallet {

 inline constexpr size_t kKeccakHashLength = 32;
 inline constexpr size_t kRipemd160HashLength = 20;
+inline constexpr size_t kSHA512HashLength = 64;


https://commondatastorage.googleapis.com/chromium-boringssl-docs/sha.h.html#SHA512_DIGEST_LENGTH

sha.h has this constant SHA512_DIGEST_LENGTH defined as 64.
We shouldn't hardcoded these ourselves.
Likewise RIPEMD160_DIGEST_LENGTH.

I didn't want to leak OpenSSL headers through this header.

Chrome is OK to hardcode this
https://source.chromium.org/chromium/chromium/src/+/main:crypto/sha2.h;l=26?q=kSHA256Length&ss=chromium
https://source.chromium.org/chromium/chromium/src/+/main:crypto/hash.h;l=15-17?q=kSha512Size&ss=chromium

bridiver · 2024-12-19T21:23:34Z

components/brave_wallet/browser/solana_keyring.cc


  // Invalid because program derived addresses have to be off-curve.
  if (bytes_are_curve25519_point(
-          rust::Slice<const uint8_t>{hash_vec.data(), hash_vec.size()})) {
+          rust::Slice<const uint8_t>{hash_array.data(), hash_array.size()})) {


base::SpanToRustSlice

bridiver · 2024-12-19T21:28:23Z

components/brave_wallet/common/hash_utils.cc

+                           base::span<const uint8_t> data) {
+  SHA512HashArray hmac;
+  unsigned int out_len = 0;
+  CHECK(HMAC(EVP_sha512(), key.data(), key.size(), data.data(), data.size(),


I don't know if we want to crash the browser if this fails, can it fail for any reason other than running out of memory? Actually no memory is heap allocated in this call so it should definitely not CHECK. See https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/c++/checks.md#failures-beyond-chromium_s-control

That's similarly CHECK'ed in many places like this
https://source.chromium.org/chromium/chromium/src/+/main:remoting/protocol/webrtc_transport.cc;l=829-831;drc=b31f44704280a3ec2acb6d7c0542cbe0ce47e53f;bpv=1;bpt=1

Nevertheless now using crypto::hmac::SignSha512 novelty

bridiver · 2024-12-19T22:16:42Z

components/brave_wallet/common/hash_utils.cc

+  unsigned int out_len = 0;
+  CHECK(HMAC(EVP_sha512(), key.data(), key.size(), data.data(), data.size(),
+             hmac.data(), &out_len));
+  CHECK_EQ(out_len, hmac.size());


same as above, this is not an appropriate use of CHECK. Any problem with the generation of the hmac should be handled by the caller, not by crashing. Maybe this should return std::optional<SHA512HashArray>?

bridiver · 2024-12-19T22:28:38Z

components/brave_wallet/browser/internal/hd_key_ed25519.h


 namespace brave_wallet {

-// This class implement basic EdDSA over ed25519 functionality of bip32-ed25519
+inline constexpr size_t kEd25519PrivateKeySize = 32;


ED25519_PRIVATE_KEY_LEN, ED25519_PUBLIC_KEY_LEN
also it looks like kEd25519PrivateKeySize is incorrect and should be 64?

32 bytes is private key size per spec.

64 bytes is what OpenSSL names as private_key which is actually a pair of private and public keys.

I had left a comment elsewhere about this, but I guess both me and Brian were confused, so I guess maybe we need some better naming, the comment above could also better explain this distinction, besides the link to the rfc.

bridiver · 2024-12-19T22:29:37Z

components/brave_wallet/browser/internal/hd_key_ed25519.h

+inline constexpr size_t kEd25519KeypairSize =
+    kEd25519PrivateKeySize + kEd25519PublicKeySize;
+inline constexpr size_t kEd25519ChainCodeSize = 32;
+inline constexpr size_t kEd25519SignatureSize = 64;


ED25519_SIGNATURE_LEN

removed by now

bridiver · 2024-12-19T22:31:50Z

components/brave_wallet/browser/internal/hd_key_ed25519.h

+inline constexpr size_t kEd25519PublicKeySize = 32;
+inline constexpr size_t kEd25519KeypairSize =
+    kEd25519PrivateKeySize + kEd25519PublicKeySize;
+inline constexpr size_t kEd25519ChainCodeSize = 32;


please provide a link or other reference for this value

bridiver · 2024-12-19T22:38:22Z

components/brave_wallet/browser/internal/hd_key_utils.cc

+  result.reserve(entries.size() - 1);
+  for (auto node : base::span(entries).subspan(1)) {
+    uint32_t offset = 0;
+    if (node.ends_with('\'')) {


please add comments for the expected format(s)

removed completely

bridiver · 2024-12-19T22:46:46Z

components/brave_wallet/browser/internal/hd_key_utils.h

+// expected to end with a single quote per BIP-44 style.
+// https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
+// https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki
+// TODO(apaymyshev): We most likely do not need this parsing as at runtime all


please create (and link) issues for TODOs

bridiver · 2024-12-19T23:55:25Z

components/brave_wallet/browser/internal/hd_key_ed25519.h

-      base::span<const uint8_t> seed);
-  static std::unique_ptr<HDKeyEd25519> GenerateFromPrivateKey(
-      base::span<const uint8_t> private_key);
+  static std::unique_ptr<HDKeyEd25519> GenerateFromSeedAndPath(


any changes to the code should be a follow-up. We don't want to mix up replacing the ed25519 implementation with other changes to the code

removed unrelated changes

bridiver · 2024-12-19T23:58:58Z

components/brave_wallet/browser/internal/hd_key_ed25519.cc

-std::vector<uint8_t> HDKeyEd25519::GetPrivateKeyBytes() const {
-  auto secret_key = private_key_->unwrap().secret_key_raw();
-  return {secret_key.begin(), secret_key.end()};
+base::span<const uint8_t, kEd25519PrivateKeySize>


are these changes to the method signature necessary for something in the new implementation? Please don't change anything that doesn't strictly need to be changed. Any other changes should be follow-ups

cdesouza-chromium · 2024-12-20T00:19:34Z

@supermassive @kdenhartog Let's have all changes to anything relating to SecureAllocator/SecureZeroBuffer to a separate PR. For this change we have to keep the vector with the special allocator as it was prior, because I think this falls outside of the scope of this change. Having said that, on a follow-up for that, please tag me for review.

supermassive · 2024-12-20T10:29:05Z

components/brave_wallet/browser/internal/hd_key_ed25519_unittest.cc

@@ -18,7 +34,6 @@ TEST(HDKeyEd25519UnitTest, TestVector1) {

  // m
  auto master_key_base = HDKeyEd25519::GenerateFromSeed(bytes);
-  EXPECT_EQ(master_key_base->GetPath(), "m");


We don't need path property at all

supermassive · 2024-12-20T10:37:30Z

@kdenhartog @Brandon-T @bridiver @cdesouza-chromium
Folks, I've removed everything not related to "replace rust crate dep with OpenSSL".
Also I did not reimplement some stuff we don't need in wallet (like derivation path string support).
PTAL!

cdesouza-chromium · 2024-12-21T11:59:30Z

components/brave_wallet/browser/internal/hd_key_ed25519.cc

+  std::array<uint8_t, ED25519_PRIVATE_KEY_LEN> key_pair = {};
+  base::span(key_pair).first<kEd25519PrivateKeySize>().copy_from(private_key);
+  base::span(key_pair).last<kEd25519PublicKeySize>().copy_from(public_key);


We have ED25519_PRIVATE_KEY_LEN, but we also have kEd25519PrivateKeySize. The distinction between these two doesn't seem very clear to me, as they have identical names.

I've changed underlying storage to key pair, added some static_asserts and comments. Hope it's more clear now.

components/brave_wallet/browser/internal/hd_key_ed25519.cc

cdesouza-chromium · 2024-12-21T12:16:03Z

components/brave_wallet/browser/internal/hd_key_ed25519.cc

 std::vector<uint8_t> HDKeyEd25519::GetPublicKeyBytes() const {
-  auto public_key = private_key_->unwrap().public_key_raw();
-  return {public_key.begin(), public_key.end()};
+  return base::ToVector(public_key_);
 }


You can do this in a follow up if you prefer, but every time someone calls GetPublicKeyBytes, it results on a copy, as we have to wrap the value on a vector. This doesn't seem to be necessary and it looks like we could just have:

const std::array<uint8_t, kEd25519PrivateKeySize> private_key() const { return private_key_; }

That in the first version of PR(actually returning span on const), but we later decided not change signature of public methods at all.

Would you mind elaborating why?

#26770 (comment)

You can do this in a follow up if you prefer

Please change this to be a reference to the member in a follow up.

components/brave_wallet/browser/internal/hd_key_ed25519.cc

github-actions · 2024-12-23T05:59:36Z

[puLL-Merge] - brave/brave-core@26770

Description

This PR updates the implementation of Ed25519 key derivation in the Brave Wallet to use a new Rust-based library (ed25519-dalek-bip32) instead of the previous C++ implementation. This change aims to improve security and maintainability by leveraging a well-tested Rust library for cryptographic operations.

Changes

Changes

components/brave_wallet/browser/BUILD.gn:
- Moved "rust_lib" from dependencies to public_deps for "hd_keyring" target
components/brave_wallet/browser/internal/BUILD.gn:
- Added "rust_lib" to public_deps for "hd_key" target
components/brave_wallet/browser/internal/hd_key_ed25519.cc:
- Completely refactored to use the new Rust-based implementation
- Removed OpenSSL dependencies
- Implemented new methods for key derivation, signing, and verification using the Rust library
components/brave_wallet/browser/internal/hd_key_ed25519.h:
- Updated class definition to match new implementation
- Added new methods and removed obsolete ones
components/brave_wallet/browser/internal/hd_key_ed25519_unittest.cc:
- Updated tests to work with the new implementation
- Added new tests for path derivation and verification
components/brave_wallet/browser/solana_keyring.cc and .h:
- Updated to work with the new HDKeyEd25519 implementation
- Modified ConstructRootHDKey to use the new derivation method
components/brave_wallet/rust/BUILD.gn:
- Added dependency on ed25519-dalek-bip32
components/brave_wallet/rust/Cargo.toml:
- Added ed25519-dalek-bip32 dependency
components/brave_wallet/rust/lib.rs:
- Implemented Rust functions to interface with the ed25519-dalek-bip32 library
- Added error handling and result types for the new functions
Added several new Rust dependencies in third_party/rust/

sequenceDiagram
    participant App as Brave Wallet App
    participant HDKeyEd25519 as HDKeyEd25519 (C++)
    participant RustLib as Rust Library
    participant Ed25519DalekBip32 as ed25519-dalek-bip32

    App->>HDKeyEd25519: Generate from seed
    HDKeyEd25519->>RustLib: generate_ed25519_extended_secret_key_from_seed
    RustLib->>Ed25519DalekBip32: ExtendedSigningKey::from_seed
    Ed25519DalekBip32-->>RustLib: ExtendedSigningKey
    RustLib-->>HDKeyEd25519: Ed25519DalekExtendedSecretKey
    HDKeyEd25519-->>App: HDKeyEd25519 instance

    App->>HDKeyEd25519: Derive child key
    HDKeyEd25519->>RustLib: derive or derive_hardened_child
    RustLib->>Ed25519DalekBip32: derive or derive_child
    Ed25519DalekBip32-->>RustLib: Derived ExtendedSigningKey
    RustLib-->>HDKeyEd25519: Derived Ed25519DalekExtendedSecretKey
    HDKeyEd25519-->>App: Derived HDKeyEd25519 instance

    App->>HDKeyEd25519: Sign message
    HDKeyEd25519->>RustLib: sign
    RustLib->>Ed25519DalekBip32: sign
    Ed25519DalekBip32-->>RustLib: Signature
    RustLib-->>HDKeyEd25519: Signature bytes
    HDKeyEd25519-->>App: Signature

Possible Issues

The change from C++ to Rust for cryptographic operations may introduce subtle differences in behavior that could affect existing wallet functionality.
The new implementation might have different performance characteristics compared to the previous one, which could impact wallet operations.

Security Hotspots

The implementation of key derivation and signing operations in the new Rust code should be carefully reviewed to ensure it follows best practices for cryptographic operations.
The interface between C++ and Rust code, especially in hd_key_ed25519.cc, should be examined to ensure no security vulnerabilities are introduced during data transfer between the two languages.

cdesouza-chromium

LGTM

github-actions bot assigned supermassive Nov 27, 2024

github-actions bot added CI/run-audit-deps Check for known npm/cargo vulnerabilities (audit_deps) feature/web3/wallet feature/web3/wallet/core labels Nov 27, 2024

supermassive force-pushed the wallet_openssl_ed25519 branch from 963dcb0 to 8f325e8 Compare November 27, 2024 08:02

supermassive marked this pull request as ready for review November 28, 2024 09:02

supermassive requested review from a team and bridiver as code owners November 28, 2024 09:03

supermassive force-pushed the wallet_openssl_ed25519 branch from e7e8470 to 1cd3484 Compare December 2, 2024 08:39

github-actions bot added the puLL-Merge label Dec 2, 2024

supermassive force-pushed the wallet_openssl_ed25519 branch 2 times, most recently from efc3048 to 0d76610 Compare December 4, 2024 08:40

kdenhartog reviewed Dec 11, 2024

View reviewed changes

supermassive force-pushed the wallet_openssl_ed25519 branch 3 times, most recently from 0198666 to dbea600 Compare December 16, 2024 03:56

bridiver requested a review from cdesouza-chromium December 19, 2024 20:18

bridiver reviewed Dec 19, 2024

View reviewed changes

Brandon-T reviewed Dec 19, 2024

View reviewed changes

bridiver reviewed Dec 19, 2024

View reviewed changes

supermassive force-pushed the wallet_openssl_ed25519 branch from dbea600 to 2d23f5a Compare December 20, 2024 10:12

supermassive commented Dec 20, 2024

View reviewed changes

supermassive force-pushed the wallet_openssl_ed25519 branch from 2d23f5a to 54d34ad Compare December 20, 2024 10:32

cdesouza-chromium reviewed Dec 21, 2024

View reviewed changes

components/brave_wallet/browser/internal/hd_key_ed25519.cc Outdated Show resolved Hide resolved

cdesouza-chromium reviewed Dec 21, 2024

View reviewed changes

components/brave_wallet/browser/internal/hd_key_ed25519.cc Outdated Show resolved Hide resolved

supermassive added 9 commits December 23, 2024 12:56

Use OpenSSL for ed25519 keys

39a4b1e

remove ed25519-dalek-bip32 crate deps

fe9e34c

fix ci

c540149

fix ci

76253e4

fix ci

f50c51e

fix review

9fe6c8b

cleanup

bd72bcc

fix review

c4edca8

fix review

c622ddb

supermassive force-pushed the wallet_openssl_ed25519 branch from 54d34ad to c622ddb Compare December 23, 2024 05:56

cdesouza-chromium approved these changes Dec 24, 2024

View reviewed changes

Wallet openssl ed25519 #26770

Are you sure you want to change the base?

Wallet openssl ed25519 #26770

Conversation

supermassive commented Nov 27, 2024 • edited Loading

Submitter Checklist:

Reviewer Checklist:

After-merge Checklist:

Test Plan:

kdenhartog left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kdenhartog Dec 11, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kdenhartog commented Dec 13, 2024 • edited Loading

cdesouza-chromium commented Dec 19, 2024

bridiver Dec 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bridiver Dec 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bridiver Dec 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bridiver Dec 19, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdesouza-chromium commented Dec 20, 2024

Choose a reason for hiding this comment

supermassive commented Dec 20, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdesouza-chromium Dec 21, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Dec 23, 2024

Description

Changes

Possible Issues

Security Hotspots

cdesouza-chromium left a comment

Choose a reason for hiding this comment

supermassive commented Nov 27, 2024 •

edited

Loading

kdenhartog Dec 11, 2024 •

edited

Loading

kdenhartog commented Dec 13, 2024 •

edited

Loading

bridiver Dec 19, 2024 •

edited

Loading

bridiver Dec 19, 2024 •

edited

Loading

bridiver Dec 19, 2024 •

edited

Loading

bridiver Dec 19, 2024 •

edited

Loading

cdesouza-chromium Dec 21, 2024 •

edited

Loading