fix(crypto): feature-gate aws-lc-rs so near-crypto builds for wasm32

[r-near]

Makes aws-lc-rs optional (still default-on) in near-crypto: the ML-DSA types and parsing stay unconditional, only sign/verify/keygen need the backend, so wasm32 consumers build again with default features off and node builds are unchanged.
Fixes #16112.

[codecov]

Codecov Report

❌ Patch coverage is 87.50000% with 3 lines in your changes missing coverage. Please review.
✅ Project coverage is 73.37%. Comparing base (54ad667) to head (d180699).

Files with missing lines	Patch %	Lines
core/crypto/src/test_utils.rs	40.00%	3 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #16113      +/-   ##
==========================================
+ Coverage   73.35%   73.37%   +0.02%     
==========================================
  Files         859      859              
  Lines      189728   189730       +2     
  Branches   189728   189730       +2     
==========================================
+ Hits       139179   139222      +43     
+ Misses      46102    46061      -41     
  Partials     4447     4447              

Flag	Coverage Δ
pytests-nightly	1.22% <0.00%> (-0.01%)	⬇️
unittests	69.99% <87.50%> (+<0.01%)	⬆️
unittests-nightly	70.04% <87.50%> (+0.01%)	⬆️
unittests-spice	65.64% <87.50%> (-0.01%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 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.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[greptile-apps]

Greptile Summary

Makes the ML-DSA backend optional while preserving it in default and workspace builds.

• Adds aws-lc-rs to near-crypto’s default features and enables it explicitly for workspace consumers.
• Gates ML-DSA key generation, signing, public-key derivation, and verification backend calls.
• Keeps ML-DSA types and parsing available without the backend.
• Aligns helper imports and ML-DSA tests with the backend feature.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains in the fixes associated with the previous review threads.

_{Reviews (5): Last reviewed commit: "test(crypto): gate ML-DSA-65 tests on th..." | Re-trigger Greptile}

[github-actions]

Pull request overview

Makes aws-lc-rs an optional (default-on) cargo feature of near-crypto so that consumers can turn it off for wasm32-unknown-unknown, where aws-lc-sys fails to build. ML-DSA types, byte layout, and borsh serialization stay unconditional; only the sign/verify/keygen paths and the ml_dsa_65_* helper functions (which take/return PqdsaKeyPair) are gated. Workspace inherit is updated to keep aws-lc-rs enabled by default for the node build, so this is a no-op for internal callers.

Changes:

• core/crypto/Cargo.toml: aws-lc-rs becomes optional = true, added to default features.
• Cargo.toml: workspace near-crypto inherit adds features = ["aws-lc-rs"] so downstream crates get the same behavior as before.
• core/crypto/src/signature.rs: #[cfg(feature = \"aws-lc-rs\")] around imports, the MLDSA65 arms of from_random/sign/public_key/verify, the FromStr validation step, and the three private helpers ml_dsa_65_secret_from_keypair / ml_dsa_65_secret_from_seed / ml_dsa_65_from_seed. With the feature off, the MLDSA65 arms hit unimplemented!(\"ML-DSA-65 requires the aws-lc-rs feature\").

Reviewed changes

Per-file summary

File	Description
Cargo.toml	Workspace near-crypto inherit sets features = [\"aws-lc-rs\"]
core/crypto/Cargo.toml	aws-lc-rs becomes optional, added to default
core/crypto/src/signature.rs	Gates ML-DSA-65 sign/verify/keygen and helper fns on aws-lc-rs; MLDSA65 arms unimplemented!() when disabled

Findings

Non-blocking (follow-ups / suggestions):

• core/crypto/src/test_utils.rs:4-7 — use crate::signature::{ ..., ml_dsa_65_from_seed } is gated on #[cfg(feature = \"rand\")] only, but after this PR ml_dsa_65_from_seed (signature.rs:917-919) requires both rand and aws-lc-rs. cargo check -p near-crypto --no-default-features --features rand will fail to compile with "cannot find ml_dsa_65_from_seed in signature". Same shape applies to the KeyType::MLDSA65 arms of PublicKey::from_seed (test_utils.rs:59-63) and SecretKey::from_seed (test_utils.rs:77-80). Current CI doesn't catch this because check-publishable-separately --no-default-features turns both features off simultaneously, and every in-tree consumer that enables rand also picks up aws-lc-rs via the workspace inherit. Suggested fix: gate the import and the MLDSA65 arms on all(feature = \"rand\", feature = \"aws-lc-rs\"), or make the private ml_dsa_65_* helpers rand-only and give them internal #[cfg(not(feature = \"aws-lc-rs\"))] unimplemented! bodies to keep symbols visible.

• core/crypto/src/signature.rs:1164-1174 — Signature::verify panics with unimplemented! when aws-lc-rs is off and the sig/pubkey pair is MLDSA65. verify is a pure -> bool function used on untrusted network input; a wasm consumer that receives an MLDSA65 signature from a peer now panics instead of returning false. Consider returning false in the disabled branch — matches the _ => false fallback used elsewhere in the same match and avoids DoS-via-untrusted-signature. sign / from_random / public_key panicking is fine (caller controls the input); verify is the one that can be reached with attacker-supplied bytes.

• core/crypto/src/signature.rs:949-959 — With aws-lc-rs disabled, the round-trip validation (PqdsaKeyPair::from_raw_private_key) in FromStr for SecretKey is skipped, so malformed-but-correct-length ML-DSA raw keys parse successfully and only blow up later. The comment above ("catches malformed-but-correct-length blobs at parse time rather than blowing up later in sign()") is now conditionally accurate. Not a correctness bug because there's no sign() to blow up when the feature is off, but worth acknowledging in the comment or leaving a note that validation is best-effort under this feature.

• core/crypto/src/signature.rs:883-884, 897-898, 917-918 — Stacked #[cfg(feature = \"rand\")] + #[cfg(feature = \"aws-lc-rs\")] is equivalent to #[cfg(all(...))] but slightly harder to skim; consider collapsing.

⚠️ Issues found

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 4cbeb01406

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[r-near]

@greptile review

[github-actions]

Pull request overview

Makes aws-lc-rs an optional (default-on) feature of near-crypto so that wasm32 consumers can turn it off (where aws-lc-sys fails to build). ML-DSA-65 types, byte layout, borsh serialization, and identifier parsing stay unconditional; only sign / verify / keygen paths and the ml_dsa_65_* helpers that return PqdsaKeyPair-derived material are gated. The workspace inherit is updated to keep aws-lc-rs enabled by default for node builds, so this is a no-op for internal callers.

Changes:

• Cargo.toml: workspace near-crypto inherit adds features = ["aws-lc-rs"].
• core/crypto/Cargo.toml: aws-lc-rs becomes optional = true and joins default.
• core/crypto/src/signature.rs: gates the aws-lc-rs imports, the MLDSA65 arms of from_random / sign / public_key, the FromStr validation step, and the private ml_dsa_65_* helpers. With the feature off, key-owner-controlled paths hit unimplemented!, and verify returns false (per the earlier P1 fix) so untrusted input can't panic the process.
• core/crypto/src/test_utils.rs: gates the ml_dsa_65_from_seed import on rand + aws-lc-rs, and the MLDSA65 arms of PublicKey::from_seed / SecretKey::from_seed on aws-lc-rs.

Reviewed changes

Per-file summary

File	Description
Cargo.toml	Workspace near-crypto inherit sets features = ["aws-lc-rs"]
core/crypto/Cargo.toml	aws-lc-rs becomes optional; added to default
core/crypto/src/signature.rs	Gates ML-DSA-65 sign/verify/keygen and helpers on aws-lc-rs; verify returns false when disabled, other arms unimplemented!
core/crypto/src/test_utils.rs	Import and MLDSA65 seed helpers gated on aws-lc-rs

Findings

Prior P1s (verify panicking on untrusted input, test_utils losing ml_dsa_65_from_seed under --no-default-features --features rand) are addressed. Remaining items are non-blocking.

Non-blocking (nits / follow-ups):

• core/crypto/src/test_utils.rs:38 — ml_dsa_65_seed_bytes_from_str is #[cfg(feature = \"rand\")] but is now only called from inside #[cfg(feature = \"aws-lc-rs\")] blocks. Under the --no-default-features --features rand combo (rand on, aws-lc-rs off — the exact combo this PR is meant to unblock for wasm), the helper compiles but has no callers, which trips dead_code under RUSTFLAGS=\"-D warnings\". CI's check-publishable-separately --no-default-features disables both features simultaneously and misses this. Suggest gating the helper on all(feature = \"rand\", feature = \"aws-lc-rs\") to match its actual call sites.

• core/crypto/src/signature.rs:951-957 — The comment above the FromStr validation still reads "Catches malformed-but-correct-length blobs at parse time rather than blowing up later in sign()", but under #[cfg(not(feature = \"aws-lc-rs\"))] the check is skipped and any subsequent sign() call also unimplemented!s. Not a correctness bug, but worth noting in the comment that the validation is best-effort under the disabled-feature build (or dropping the mention of sign()).

• core/crypto/src/signature.rs:883-884, 897-898, 917-918 — Stacked #[cfg(feature = \"rand\")] + #[cfg(feature = \"aws-lc-rs\")] is equivalent to #[cfg(all(feature = \"rand\", feature = \"aws-lc-rs\"))] but a touch harder to skim. Collapsing them is a small readability win.

✅ Approved

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 7a0fe83075

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[github-actions]

Pull request overview

Makes aws-lc-rs an optional (default-on) feature of near-crypto so consumers can turn it off for wasm32-unknown-unknown, where aws-lc-sys fails to build. ML-DSA-65 types, byte layout, borsh serialization, and identifier parsing stay unconditional; only sign/verify/keygen and the ml_dsa_65_* helpers that return PqdsaKeyPair-derived material are gated. The workspace inherit adds features = [\"aws-lc-rs\"] so node builds are unchanged.

Changes:

• Cargo.toml: workspace near-crypto inherit adds features = [\"aws-lc-rs\"].
• core/crypto/Cargo.toml: aws-lc-rs becomes optional = true, joins default.
• core/crypto/src/signature.rs: gates imports, MLDSA65 arms of from_random / sign / public_key, the FromStr round-trip validation, and the private ml_dsa_65_* helpers on aws-lc-rs. With the feature off, key-owner paths hit unimplemented!, and verify returns false so attacker-supplied input can't panic the process. MLDSA65 unit tests are gated too.
• core/crypto/src/test_utils.rs: gates the ml_dsa_65_from_seed import and the MLDSA65 arms of PublicKey::from_seed / SecretKey::from_seed on aws-lc-rs.

Reviewed changes

Per-file summary

File	Description
Cargo.toml	Workspace near-crypto inherit adds features = [\"aws-lc-rs\"]
core/crypto/Cargo.toml	aws-lc-rs becomes optional; added to default
core/crypto/src/signature.rs	Gates ML-DSA-65 sign/verify/keygen and helpers on aws-lc-rs; verify returns false when disabled; tests gated
core/crypto/src/test_utils.rs	Import and MLDSA65 seed helpers gated on aws-lc-rs

Findings

The previously flagged P1s — verify panicking on untrusted MLDSA65 input (signature.rs:1162), and --no-default-features --features rand failing to compile because test_utils still imported ml_dsa_65_from_seed (test_utils.rs:1–3) / called it in from_seed (test_utils.rs:60, 86) — are all fixed in this branch. No new blocking issues.

The three non-blocking follow-ups already noted in the last automated review still apply and are worth a quick pass before merge:

• core/crypto/src/test_utils.rs:38 — ml_dsa_65_seed_bytes_from_str is gated on #[cfg(feature = \"rand\")] but is only called from inside #[cfg(feature = \"aws-lc-rs\")] blocks; under --features rand without aws-lc-rs it becomes dead code and would warn under -D warnings. Gate it on all(feature = \"rand\", feature = \"aws-lc-rs\") to match its call sites. (CI's --all-features clippy pass masks this.)
• core/crypto/src/signature.rs:951–957 — the comment above the FromStr round-trip validation still says the check catches malformed blobs "rather than blowing up later in sign()", but under not(aws-lc-rs) both the check and any later sign() are gone. Worth noting the validation is best-effort under the disabled-feature build, or dropping the sign() mention.
• core/crypto/src/signature.rs:883–884, 897–898, 917–918 — stacked #[cfg(feature = \"rand\")] + #[cfg(feature = \"aws-lc-rs\")] are equivalent to #[cfg(all(...))]; collapsing is a small readability win.

✅ Approved

[Wiezzel]

I'd rather name the feature ml-dsa-65 than aws-lc-rs. The external crate name is not very informative.

Additionally, I recommend adding warnings to the relevant functions' docstrings that they panic when the feature is not enabled.