Update PQC Draft to Version 12 by TJ-91 · Pull Request #2355 · rnpgp/rnp

TJ-91 · 2025-07-14T08:56:00Z

This PR updates to the newest PQC draft version, and adds/fixes some RFC 9580 functionality. The PR replaces #2287. The PQC draft can be seen as stable now since it has passed Working Group Last Call recently.

The most prominent changes are:

V6 / RFC 9580

correctly implement v6 salt for document signatures (was only properly working for key signatures before)
- change HashList for use with salt
- implement v6 OPS with salt
- gracefully fail when verifying v6 cleartext signatures by skipping them. Due to the salt that is detected at the end, two passes are required which requires further changes to the code.
add Ed448 and X448 standalone algorithms

PQC

update Kyber, Dilithium and Sphincs+ to final PQC NIST algorithms: ML-KEM, ML-DSA, SLH-DSA
update to PQC draft version 12:
- add X448 and Ed448 for composite PQC combinations
- implement SHA3 KEM Combiner (replaces KMAC)
- remove Sphincsplus/SLH-DSA parametrization
- implement tests / test vectors
- seed format for ML-KEM/ML-DSA private keys
also update to use the new codepoints in the upcoming draft-ietf-openpgp-nist-bp-comp-02

Further Code Changes

~~PQC code is not independent from Crypto Refresh / RFC9580 any more and thus ENABLE_CRYPTO_REFRESH is required for ENABLE_PQC~~ This is changed again in newer commits to allow MLKEM768+X25519 for v4 keys without compiling the crypto refresh code.
ENABLE_CRYPTO_REFRESH and ENABLE_PQC now requires Botan 3.6.
- Ed448/X448 only available from 3.4
- PQC final NIST standards available from Botan 3.6
- Supporting partial features from lower Botan versions would mean to either have lots of deprecation warnings or have special code for the different versions.
Since RIPEMD is also deprecated in RFC 9580, I added a Security Rule that marks it insecure like SHA1 if CRYPTO_REFRESH_ENABLED is true.
- I don't know what date would be most appropriate though

@ni4 since I had to rebase a lot and fixed some stuff only at the end of the rebasing, the history is not perfectly intact. Please tell me if you prefer to keep the commits anyway or whether I should squash them into a single commit. I hope I did not mess anything up when rebasing.

As next steps I would like to rebase the other PRs #2296 and #2207 (that is considerably less code than in this PR).

codecov · 2025-07-14T09:32:15Z

Codecov Report

❌ Patch coverage is 94.00000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 85.46%. Comparing base (6f8a677) to head (1645560).

Files with missing lines	Patch %	Lines
src/lib/crypto/signatures.cpp	0.00%	1 Missing ⚠️
src/librepgp/stream-packet.cpp	93.33%	1 Missing ⚠️
src/librepgp/stream-sig.cpp	83.33%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2355   +/-   ##
=======================================
  Coverage   85.46%   85.46%           
=======================================
  Files         126      126           
  Lines       22711    22732   +21     
=======================================
+ Hits        19409    19428   +19     
- Misses       3302     3304    +2

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

TJ-91 · 2025-07-18T10:11:08Z

@ni4 3 checks fail due to the Botan version (3.6.0 required now). I suppose the images can easily be changed (or alternatively RFC95080/PQC disabled) in the corresponding yml files. I'm not familiar with your CI/CD setup, therefore I think someone else should do the necessary changes.

kaie · 2026-05-19T13:52:10Z

Hi Johannes, would it be easy for you to rebase your PR?

Nickolay said the CI issues should be fixed, so maybe merging will be possible soon.

If you don't have time, Nickolay said he could replicate your PR.

... for rnp_generate_key_ex add roundtrip test for PQC certs clang-format

require Botan 3.6.0 for PQC switch to final NIST PQC standards update KMAC Key Combiner

fail gracefully on parsing v6 cleartext sigs

…nabled

TJ-91 · 2026-05-19T14:06:02Z

Hi Kai, since GitHub says there are no conflicts, it is easy for me, yes :)

kaie · 2026-05-19T14:18:52Z

Great, thanks a lot!

TJ-91 · 2026-05-19T16:02:28Z

It seems like there are still some issues either with the CI or with my code. Unfortunately I don't have a lot of time right now to take care of this.

FYI, I have set "Allow edits and access to secrets by maintainers" if Nickolay finds the time.

kaie · 2026-06-01T11:49:30Z

I get a build warning when building against Botan 3.11.1 [edited: warning, not error]

In file kyber_ecdh_composite.h a forward declaration is added "struct pgp_kyber_ecdh_composite_public_key_t;",
but the type is rather declared as a class, not a struct.

kaie · 2026-06-01T19:07:29Z

The CI runs that uses the openssl backend fails because it is not yet available for pqc in this PR.
(That applies for the initial build job, and also the failing opensuse job.)
That CI run passes in PR 2392 which adds such a backend.

The two CI runs that use Botan 3.3.0 fail because that workflow enables PQC, but that configuration requires at least Botan 3.6.0
I've asked for guidance in issue #2393 how that workflow should be fixed.

The fuzzing build has the same issue, but it requires a patch for oss-fuzz.
@ni4 could you please submit an update there?

The issues in windows did NOT happen in the latest CI runs in my PR #2392.
I cannot explain why.

In the other CI runs for my recent pull requests, I see a new failure appearing,
in rnp_tests.test_cipher_aes_128_ocb
that happened both in PR #2392 and and in PR #2391
In both places the test failed when using Botan HEAD, so maybe it is caused by a recent change in Botan?

I would like to suggest that you add workflows that use Botan 3.11.1 or 3.12
to test against a recent stable version of Botan.

ni4

While there are some CI failures they don't seem relevant and we may fix those later. LGTM!

ronaldtse

Thank you @TJ-91 and everyone!

…ak-hash binding) Audit-driven polish on top of PR #2355 to close the remaining RFC 9980 compliance gaps. Three changes, one story: make rnp's PQC implementation fully RFC 9980-conformant on the receiver and keygen sides. G1 — Preferred AEAD Ciphersuites for PQ keys (RFC 9980 §7.1) UserPrefs::check_defaults() now populates aead_prefs from symm_algs not only for v6 keys (the prior behaviour) but also for any key whose public-key algorithm is PQ. This ensures v4 ML-KEM-768+X25519 keys also advertise AES-256+OCB, satisfying the RFC's SHOULD for all PQ certs rather than just v6. G3 — Reject weak-hash subkey binding signatures over PQ subkeys (RFC 9980 §7.2) Key::validate_binding() now rejects MD5, SHA-1, and RIPEMD-160 in subkey binding signatures (type 0x18) when the subkey's algorithm is one of the PQ(/T) algorithms. The RFC says a receiving implementation MUST treat such signatures as invalid; rnp now does. G4 — Canonical algorithm name strings (RFC 9980 §2.1) rnp_keygen_alg_map in src/lib/keygen.cpp used hardcoded strings with underscore separators ("ML-KEM-768_X25519") and two outdated names that don't match RFC 9980 at all ("Kyber-X448" for alg ID 36 and "Dilithium-ED448" for alg ID 31). Now uses the RNP_ALGNAME_* macros from include/rnp/rnp.h, which already use the canonical RFC 9980 "+" form. This makes both internal maps consistent and matches the wire-spec naming. G2 (deferred): RFC 9980 §7.1 also specifies that a receiver should implicitly append AES-256 to a PQ recipient's preferences if it's missing. rnp does not have a recipient-pref-intersection code path today (callers choose the cipher via rnp_op_encrypt_set_cipher), so there's nothing to add AES-256 to. This item is moot until rnp grows recipient-driven cipher selection.

…follow-ups) The merged PRs #2355 (PQC draft 12 + v6 salt + Ed448/X448) and #2296 (Argon2 S2K + AEAD secret-key encryption) shipped with happy-path coverage only — import sample, verify, decrypt with correct password. This PR adds the missing negative coverage: - test_ffi_argon2_locked_seckey_wrong_password: wrong password must fail cleanly and not leave the key in a partial-unlock state; subsequent correct password still works after multiple failures. - test_ffi_decrypt_argon2_skesk_wrong_password: SKESK decryption fails without leaking plaintext when the derived AEAD key is wrong. - test_ffi_decrypt_pqc_pkesk_corrupted: a single byte flip near the end of a valid PQC-encrypted message must cause decryption to fail (exercises the AEAD tag verification path on the PQC PKESK). These close the "happy-path only" codecov gap for the AEAD-tag verification paths in stream-parse.cpp (PR #2422's earlier fix extends to PQC ciphertexts too) and for the Argon2 S2K derivation failure path in stream-key.cpp. Note: locally the build is blocked by a pre-existing Botan 3.12 API incompatibility in src/lib/crypto/ec.cpp (uses Botan::EC_Group members that became opaque in 3.12). CI runs against the Botan version pinned in the centos-and-fedora workflow (3.6 / 3.12 from source) where this is not an issue.

…ak-hash binding) Audit-driven polish on top of PR #2355 to close the remaining RFC 9980 compliance gaps. Three changes, one story: make rnp's PQC implementation fully RFC 9980-conformant on the receiver and keygen sides. G1 — Preferred AEAD Ciphersuites for PQ keys (RFC 9980 §7.1) UserPrefs::check_defaults() now populates aead_prefs from symm_algs not only for v6 keys (the prior behaviour) but also for any key whose public-key algorithm is PQ. This ensures v4 ML-KEM-768+X25519 keys also advertise AES-256+OCB, satisfying the RFC's SHOULD for all PQ certs rather than just v6. G3 — Reject weak-hash subkey binding signatures over PQ subkeys (RFC 9980 §7.2) Key::validate_binding() now rejects MD5, SHA-1, and RIPEMD-160 in subkey binding signatures (type 0x18) when the subkey's algorithm is one of the PQ(/T) algorithms. The RFC says a receiving implementation MUST treat such signatures as invalid; rnp now does. G4 — Canonical algorithm name strings (RFC 9980 §2.1) rnp_keygen_alg_map in src/lib/keygen.cpp used hardcoded strings with underscore separators ("ML-KEM-768_X25519") and two outdated names that don't match RFC 9980 at all ("Kyber-X448" for alg ID 36 and "Dilithium-ED448" for alg ID 31). Now uses the RNP_ALGNAME_* macros from include/rnp/rnp.h, which already use the canonical RFC 9980 "+" form. This makes both internal maps consistent and matches the wire-spec naming. G2 (deferred): RFC 9980 §7.1 also specifies that a receiver should implicitly append AES-256 to a PQ recipient's preferences if it's missing. rnp does not have a recipient-pref-intersection code path today (callers choose the cipher via rnp_op_encrypt_set_cipher), so there's nothing to add AES-256 to. This item is moot until rnp grows recipient-driven cipher selection.

…follow-ups) The merged PRs #2355 (PQC draft 12 + v6 salt + Ed448/X448) and #2296 (Argon2 S2K + AEAD secret-key encryption) shipped with happy-path coverage only — import sample, verify, decrypt with correct password. This PR adds the missing negative coverage: - test_ffi_argon2_locked_seckey_wrong_password: wrong password must fail cleanly and not leave the key in a partial-unlock state; subsequent correct password still works after multiple failures. - test_ffi_decrypt_argon2_skesk_wrong_password: SKESK decryption fails without leaking plaintext when the derived AEAD key is wrong. - test_ffi_decrypt_pqc_pkesk_corrupted: a single byte flip near the end of a valid PQC-encrypted message must cause decryption to fail (exercises the AEAD tag verification path on the PQC PKESK). These close the "happy-path only" codecov gap for the AEAD-tag verification paths in stream-parse.cpp (PR #2422's earlier fix extends to PQC ciphertexts too) and for the Argon2 S2K derivation failure path in stream-key.cpp. Note: locally the build is blocked by a pre-existing Botan 3.12 API incompatibility in src/lib/crypto/ec.cpp (uses Botan::EC_Group members that became opaque in 3.12). CI runs against the Botan version pinned in the centos-and-fedora workflow (3.6 / 3.12 from source) where this is not an issue.

…ak-hash binding) Audit-driven polish on top of PR #2355 to close the remaining RFC 9980 compliance gaps. Three changes, one story: make rnp's PQC implementation fully RFC 9980-conformant on the receiver and keygen sides. G1 — Preferred AEAD Ciphersuites for PQ keys (RFC 9980 §7.1) UserPrefs::check_defaults() now populates aead_prefs from symm_algs not only for v6 keys (the prior behaviour) but also for any key whose public-key algorithm is PQ. This ensures v4 ML-KEM-768+X25519 keys also advertise AES-256+OCB, satisfying the RFC's SHOULD for all PQ certs rather than just v6. G3 — Reject weak-hash subkey binding signatures over PQ subkeys (RFC 9980 §7.2) Key::validate_binding() now rejects MD5, SHA-1, and RIPEMD-160 in subkey binding signatures (type 0x18) when the subkey's algorithm is one of the PQ(/T) algorithms. The RFC says a receiving implementation MUST treat such signatures as invalid; rnp now does. G4 — Canonical algorithm name strings (RFC 9980 §2.1) rnp_keygen_alg_map in src/lib/keygen.cpp used hardcoded strings with underscore separators ("ML-KEM-768_X25519") and two outdated names that don't match RFC 9980 at all ("Kyber-X448" for alg ID 36 and "Dilithium-ED448" for alg ID 31). Now uses the RNP_ALGNAME_* macros from include/rnp/rnp.h, which already use the canonical RFC 9980 "+" form. This makes both internal maps consistent and matches the wire-spec naming. G2 (deferred): RFC 9980 §7.1 also specifies that a receiver should implicitly append AES-256 to a PQ recipient's preferences if it's missing. rnp does not have a recipient-pref-intersection code path today (callers choose the cipher via rnp_op_encrypt_set_cipher), so there's nothing to add AES-256 to. This item is moot until rnp grows recipient-driven cipher selection.

…follow-ups) The merged PRs #2355 (PQC draft 12 + v6 salt + Ed448/X448) and #2296 (Argon2 S2K + AEAD secret-key encryption) shipped with happy-path coverage only — import sample, verify, decrypt with correct password. This PR adds the missing negative coverage: - test_ffi_argon2_locked_seckey_wrong_password: wrong password must fail cleanly and not leave the key in a partial-unlock state; subsequent correct password still works after multiple failures. - test_ffi_decrypt_argon2_skesk_wrong_password: SKESK decryption fails without leaking plaintext when the derived AEAD key is wrong. - test_ffi_decrypt_pqc_pkesk_corrupted: a single byte flip near the end of a valid PQC-encrypted message must cause decryption to fail (exercises the AEAD tag verification path on the PQC PKESK). These close the "happy-path only" codecov gap for the AEAD-tag verification paths in stream-parse.cpp (PR #2422's earlier fix extends to PQC ciphertexts too) and for the Argon2 S2K derivation failure path in stream-key.cpp. Note: locally the build is blocked by a pre-existing Botan 3.12 API incompatibility in src/lib/crypto/ec.cpp (uses Botan::EC_Group members that became opaque in 3.12). CI runs against the Botan version pinned in the centos-and-fedora workflow (3.6 / 3.12 from source) where this is not an issue.

…ak-hash binding) Audit-driven polish on top of PR #2355 to close the remaining RFC 9980 compliance gaps. Three changes, one story: make rnp's PQC implementation fully RFC 9980-conformant on the receiver and keygen sides. G1 — Preferred AEAD Ciphersuites for PQ keys (RFC 9980 §7.1) UserPrefs::check_defaults() now populates aead_prefs from symm_algs not only for v6 keys (the prior behaviour) but also for any key whose public-key algorithm is PQ. This ensures v4 ML-KEM-768+X25519 keys also advertise AES-256+OCB, satisfying the RFC's SHOULD for all PQ certs rather than just v6. G3 — Reject weak-hash subkey binding signatures over PQ subkeys (RFC 9980 §7.2) Key::validate_binding() now rejects MD5, SHA-1, and RIPEMD-160 in subkey binding signatures (type 0x18) when the subkey's algorithm is one of the PQ(/T) algorithms. The RFC says a receiving implementation MUST treat such signatures as invalid; rnp now does. G4 — Canonical algorithm name strings (RFC 9980 §2.1) rnp_keygen_alg_map in src/lib/keygen.cpp used hardcoded strings with underscore separators ("ML-KEM-768_X25519") and two outdated names that don't match RFC 9980 at all ("Kyber-X448" for alg ID 36 and "Dilithium-ED448" for alg ID 31). Now uses the RNP_ALGNAME_* macros from include/rnp/rnp.h, which already use the canonical RFC 9980 "+" form. This makes both internal maps consistent and matches the wire-spec naming. G2 (deferred): RFC 9980 §7.1 also specifies that a receiver should implicitly append AES-256 to a PQ recipient's preferences if it's missing. rnp does not have a recipient-pref-intersection code path today (callers choose the cipher via rnp_op_encrypt_set_cipher), so there's nothing to add AES-256 to. This item is moot until rnp grows recipient-driven cipher selection.

…follow-ups) The merged PRs #2355 (PQC draft 12 + v6 salt + Ed448/X448) and #2296 (Argon2 S2K + AEAD secret-key encryption) shipped with happy-path coverage only — import sample, verify, decrypt with correct password. This PR adds the missing negative coverage: - test_ffi_argon2_locked_seckey_wrong_password: wrong password must fail cleanly and not leave the key in a partial-unlock state; subsequent correct password still works after multiple failures. - test_ffi_decrypt_argon2_skesk_wrong_password: SKESK decryption fails without leaking plaintext when the derived AEAD key is wrong. - test_ffi_decrypt_pqc_pkesk_corrupted: a single byte flip near the end of a valid PQC-encrypted message must cause decryption to fail (exercises the AEAD tag verification path on the PQC PKESK). These close the "happy-path only" codecov gap for the AEAD-tag verification paths in stream-parse.cpp (PR #2422's earlier fix extends to PQC ciphertexts too) and for the Argon2 S2K derivation failure path in stream-key.cpp. Note: locally the build is blocked by a pre-existing Botan 3.12 API incompatibility in src/lib/crypto/ec.cpp (uses Botan::EC_Group members that became opaque in 3.12). CI runs against the Botan version pinned in the centos-and-fedora workflow (3.6 / 3.12 from source) where this is not an issue.

…ak-hash binding) Audit-driven polish on top of PR #2355 to close the remaining RFC 9980 compliance gaps. Three changes, one story: make rnp's PQC implementation fully RFC 9980-conformant on the receiver and keygen sides. G1 — Preferred AEAD Ciphersuites for PQ keys (RFC 9980 §7.1) UserPrefs::check_defaults() now populates aead_prefs from symm_algs not only for v6 keys (the prior behaviour) but also for any key whose public-key algorithm is PQ. This ensures v4 ML-KEM-768+X25519 keys also advertise AES-256+OCB, satisfying the RFC's SHOULD for all PQ certs rather than just v6. G3 — Reject weak-hash subkey binding signatures over PQ subkeys (RFC 9980 §7.2) Key::validate_binding() now rejects MD5, SHA-1, and RIPEMD-160 in subkey binding signatures (type 0x18) when the subkey's algorithm is one of the PQ(/T) algorithms. The RFC says a receiving implementation MUST treat such signatures as invalid; rnp now does. G4 — Canonical algorithm name strings (RFC 9980 §2.1) rnp_keygen_alg_map in src/lib/keygen.cpp used hardcoded strings with underscore separators ("ML-KEM-768_X25519") and two outdated names that don't match RFC 9980 at all ("Kyber-X448" for alg ID 36 and "Dilithium-ED448" for alg ID 31). Now uses the RNP_ALGNAME_* macros from include/rnp/rnp.h, which already use the canonical RFC 9980 "+" form. This makes both internal maps consistent and matches the wire-spec naming. G2 (deferred): RFC 9980 §7.1 also specifies that a receiver should implicitly append AES-256 to a PQ recipient's preferences if it's missing. rnp does not have a recipient-pref-intersection code path today (callers choose the cipher via rnp_op_encrypt_set_cipher), so there's nothing to add AES-256 to. This item is moot until rnp grows recipient-driven cipher selection.

TJ-91 mentioned this pull request Jul 14, 2025

Update draft 06 #2287

Closed

github-advanced-security AI found potential problems Jul 14, 2025

View reviewed changes

Comment thread src/tests/ffi-key.cpp Fixed

TJ-91 force-pushed the update-draft-12 branch from b59c4db to ae08ba2 Compare July 14, 2025 10:13

This was referenced Oct 29, 2025

botan deprecations with botan 3 #2362

Open

Avoid returning enum in boolean context #2364

Merged

TJ-91 force-pushed the update-draft-12 branch 3 times, most recently from 121d8b8 to e1af516 Compare November 6, 2025 14:56

kaie mentioned this pull request Nov 7, 2025

Support ML-KEM-768+X25519 (algorithm ID 35) in the default build configuration #2370

Open

TJ-91 added 18 commits May 19, 2026 15:57

change parametrized SPHINCS+ to separate SPHINCS+ algorithms

37f8f79

improve v6 enc test

9fa28a3

fix key generation PQC hash requirements

d8c8e17

... for rnp_generate_key_ex add roundtrip test for PQC certs clang-format

Update PQC to draft-05

7084c5d

require Botan 3.6.0 for PQC switch to final NIST PQC standards update KMAC Key Combiner

update C-R code to botan 3.6.0

201ad4a

add X448/Ed448 (PQC and standalone)

d4c54db

update order in KEM combiner: PQ first

67e2844

update PQC test vectors; partially implement V6 OPS

e5cc462

fix v6 signature salt and add some test vectors

a392172

fail gracefully on parsing v6 cleartext sigs

Some cleanup and refactoring

e0abc5d

update PQC test vectors to -06 draft

7f582ce

fix pqc signature hash binding

cfacff3

sensible values in ec_curves for Ed448/X448

a63049f

fix some stuff after rebase

49e47a4

set SHA3 support for PQC keys; fix backwards compatible key gen option

9376a82

KMAC to SHA3 KEM Combiner

6b59f3e

update SPHINCS+ to SLHDSA

4d752dd

some fixes

fc0e3d9

TJ-91 added 2 commits May 19, 2026 15:57

more modern preferences for rfc9580/pqc

f9b7ab1

don't set filename/timestamp when signing files with Crypto Refresh e…

1645560

…nabled

TJ-91 force-pushed the update-draft-12 branch from e1af516 to 1645560 Compare May 19, 2026 14:06

kaie mentioned this pull request May 29, 2026

Add an automatically generated OpenSSL backend for the Crypto Refresh and PQC code #2392

Merged

kaie mentioned this pull request Jun 1, 2026

Fix Workflows for Crypto Refresh and PQC configurations #2393

Closed

ni4 requested review from ni4 and ronaldtse July 16, 2026 07:03

ni4 approved these changes Jul 16, 2026

View reviewed changes

ronaldtse approved these changes Jul 16, 2026

View reviewed changes

ronaldtse merged commit fdaea97 into rnpgp:main Jul 16, 2026
124 of 131 checks passed

This was referenced Jul 25, 2026

ffi: rnp_key_protect_ex() with Argon2 + AEAD, and PQC/Argon2 negative tests #2431

Open

ffi: add rnp_key_protect_ex() with Argon2 + AEAD support #2432

Merged

rfc9980: close small compliance gaps (G1+G3+G4) #2433

Open

Navigation Menu

Repository navigation

Update PQC Draft to Version 12 - #2355

Update PQC Draft to Version 12#2355
ronaldtse merged 37 commits into
rnpgp:mainfrom
TJ-91:update-draft-12

TJ-91 commented Jul 14, 2025 •

edited

Loading

Uh oh!

codecov Bot commented Jul 14, 2025 •

edited

Loading

Uh oh!

Uh oh!

TJ-91 commented Jul 18, 2025

Uh oh!

kaie commented May 19, 2026 •

edited

Loading

Uh oh!

TJ-91 commented May 19, 2026

Uh oh!

kaie commented May 19, 2026

Uh oh!

TJ-91 commented May 19, 2026 •

edited

Loading

Uh oh!

kaie commented Jun 1, 2026 •

edited

Loading

Uh oh!

kaie commented Jun 1, 2026

Uh oh!

ni4 left a comment

Uh oh!

ronaldtse left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

Conversation

TJ-91 commented Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

V6 / RFC 9580

PQC

Further Code Changes

Uh oh!

codecov Bot commented Jul 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

TJ-91 commented Jul 18, 2025

Uh oh!

kaie commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

TJ-91 commented May 19, 2026

Uh oh!

kaie commented May 19, 2026

Uh oh!

TJ-91 commented May 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kaie commented Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kaie commented Jun 1, 2026

Uh oh!

ni4 left a comment

Choose a reason for hiding this comment

Uh oh!

ronaldtse left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

TJ-91 commented Jul 14, 2025 •

edited

Loading

codecov Bot commented Jul 14, 2025 •

edited

Loading

kaie commented May 19, 2026 •

edited

Loading

TJ-91 commented May 19, 2026 •

edited

Loading

kaie commented Jun 1, 2026 •

edited

Loading