[barakeinav1]

Closes #4913

why is this safe #4913 (comment)

[github-actions]

Pull request overview

Unblocks cargo deny check advisories, which fails on every PR since RUSTSEC-2026-0387 (constant-time leaks in crypto-bigint, patched in >= 0.7.6). The lockfile moves the 0.7 line from 0.7.5 to 0.7.6, and the advisory is added to the deny.toml ignore list for the remaining crypto-bigint 0.5.5 copy, which has no patched release and is reached only through elliptic-curve 0.13.8 (k256 0.13.4, ecdsa 0.16.9, and p256 0.13.2 via nearcore's VM). Removal of the ignore is tracked in #4916.

I verified: the "Extra CI checks" job (cargo-deny with advisories) passes on this head; the lockfile already carries ctutils 0.4.5, which satisfies both crypto-bigint 0.7.6's ctutils = "0.4.5" requirement and the related RUSTSEC-2026-0385 (>= 0.4.4); the only direct bigint use in the workspace outside #[cfg(test)] is Reduce<U256>/Reduce<U512> on k256 scalars and the Bounded trait, both of which stay on k256's own reduction code; and the borrowing_sub branch really was introduced by crypto-bigint#1029 (Dec 2025, 0.7 line) and fixed in #1358, so 0.5.5's WideWord-based sbb is unaffected by that item.

Changes:

• Cargo.lock: bump crypto-bigint 0.7.5 → 0.7.6 and re-point its three dependents (elliptic-curve 0.14.1, primefield 0.14.0, rfc6979 0.6.0). No other lock changes.
• deny.toml: ignore RUSTSEC-2026-0387 with a TODO(#4916) and a justification for why 0.5.5 is not reachable through affected code paths.

Reviewed changes

Per-file summary

File	Description
Cargo.lock	crypto-bigint 0.7.5 → 0.7.6 (new checksum); dependents elliptic-curve 0.14.1, primefield 0.14.0, rfc6979 0.6.0 updated to the new version string.
deny.toml	Appends RUSTSEC-2026-0387 to [advisories].ignore with a TODO(#4916) and rationale, following the existing entry style.

Findings

Non-blocking (nits, follow-ups, suggestions):

• deny.toml:87 — "the leaks are in 0.7 code" is only exact for the subtraction item. The zero-counting and Reciprocal::new paths that 0.7.6 hardened in Fix CT leaks in CTZ, div_rem, nlimbs, and Montgomery mul RustCrypto/crypto-bigint#1360 (Limb::trailing_zeros/leading_zeros delegating to the primitive integer methods) have the same shape in 0.5.5, so the sentence that actually carries the argument is the next one: k256 0.13 scalars (and elliptic-curve's ScalarPrimitive) reach only the mask-based add_mod/sub_mod/neg_mod and sbb-based comparisons. Suggest narrowing the wording so a future reader does not take "absent from 0.5.5" as the justification, e.g.:

  # TODO(#4916): remove once elliptic-curve 0.13 and its crypto-bigint 0.5.5 leave the tree.
  # No patched 0.5.x exists. 0.5.5's `sbb` predates the branch crypto-bigint#1029 introduced into
  # `borrowing_sub`, and the zero-counting, division and Montgomery paths 0.7.6 hardened are never
  # reached: k256 0.13 scalars and elliptic-curve's `ScalarPrimitive` use only 0.5.5's mask-based
  # add/sub/neg mod and comparisons, with k256's own multiplication and inversion.
  "RUSTSEC-2026-0387", # crypto-bigint constant-time leaks

• Cargo.lock:2572 — optional: 0.7.7 (fixes mul_mod_special boundary cases) and 0.7.8 were released on Oct 24–25. The advisory only needs >= 0.7.6, and the 0.7 line is reached here only through near-kit's k256 0.14, so this is fine as-is; just noting it in case you re-run the update anyway.

✅ Approved