Repository navigation
Resolve RUSTSEC-2026-0387 in OpenID Connect's crypto-bigint dependency chain #425
Description
Required Rust advisory CI currently fails for crypto-bigint 0.5.5 (RUSTSEC-2026-0387). This is present in main's lockfile and is also blocking PR #424 / the #423 P0 work.
Dependency chain: marreq-core -> openidconnect 4.0.1 -> p256/p384 -> elliptic-curve 0.13.8 -> crypto-bigint 0.5.5. RustSec requires crypto-bigint >=0.7.6. The current stable openidconnect release is 4.0.1; its elliptic-curve generation does not accept that major upgrade. A direct Cargo lockfile patch cannot safely substitute an incompatible public API. No advisory allowlist or weakened gate is proposed.
In #424, compatible lockfile updates fix Tokio's RUSTSEC-2026-0384 and ctutils' RUSTSEC-2026-0385. The MCP production npm audit is also fixed. RUSTSEC-2026-0387 remains.
Investigate an upstream backport or coordinated OpenID Connect / RustCrypto dependency release. If authentication dependency changes are necessary, regression-test the actual enabled OIDC signing algorithms and provider flows before upgrading; do not remove algorithm support merely to make the audit green.
Acceptance: cargo deny check advisories passes without adding an ignore for this advisory; Rust workspace tests and delegated/external authentication integration tests pass; any supported-algorithm changes are explicitly reviewed.
References: https://rustsec.org/advisories/RUSTSEC-2026-0387.html and RustCrypto/crypto-bigint#1365
Activity
mariusmm commentedon Oct 29, 2026
Status update: #426 (merged) cleared the other advisories from this list — tokio 1.54.1 (RUSTSEC-2026-0384), ctutils 0.4.6 (RUSTSEC-2026-0385), yoke-derive 0.8.4 (yanked) and the mcp-server npm audit.
It also added a temporary
ignoreentry for RUSTSEC-2026-0387 todeny.tomlsolintis not red onmainand every Dependabot PR while this is open. That conflicts with this issue's acceptance criterion ("passes without adding an ignore"), so it should be read as a stopgap, not a resolution. The reason recorded there is that the chain (openidconnect 4.0.1 -> p256/p384 -> elliptic-curve 0.13.8 -> crypto-bigint 0.5.5) is only used for ES256/ES384 ID-token signature verification with providers' public keys. That reasoning has not been independently reviewed.This issue stays open. Removing the
RUSTSEC-2026-0387entry fromdeny.tomlis part of the acceptance criteria, and #424 / #423 should not claim "no audit gate relaxed" until it is gone.