Repository navigation
deps: replace yanked chacha20 0.10.0 with fixed 0.10.2 before launch #2728
Description
Measured scope
Assay main f1e2fb644688a7768f12479b227ddde5c9328860 and the published assay-mcp-server 5.5.1 package lock chacha20 0.10.0. A fresh crates.io cargo install --version '=5.5.1' --locked warns that this version is yanked. The downloaded Assay package SHA-256 is 7160c98cfe32f706880156c5d563c0c7ec01b642af6693ac2d1f5d4a9ce03355, checked against the registry index before installation and again against Cargo's own downloaded archive.
The upstream yank PR #583 explicitly attributes the yank of 0.10.0 and 0.10.1 to undefined behavior in the SSE2 backend. Fix #580, released as 0.10.2 on 2026-08-27, removes an SSE4.1 intrinsic from a path gated only for SSE2. Report #579 contains upstream Miri evidence. The crates.io index currently marks 0.10.2 unyanked.
cargo tree --locked --target x86_64-unknown-linux-gnu -e normal,build -i chacha20 against the published package returned:
chacha20 0.10.0
rand 0.10.0
object_store 0.14.1
assay-evidence 5.5.1
assay-adapter-api 5.5.1
assay-core 5.5.1
assay-mcp-server 5.5.1
assay-metrics 5.5.1 -> assay-mcp-server 5.5.1
This is a normal/build dependency route, not merely a dev dependency. Assay enables object_store's aws/http features; the published object_store source uses rand in client backoff and DNS paths. This establishes a compiled dependency and relevant callers, not a reproduced Assay crash. The first offline tree attempt failed for missing target-specific cached crates; the network-enabled, still-locked retry succeeded without a build.
Priority and boundary
P1 for the production-launch candidate: a small fixed upstream dependency should replace known UB in a supported x86 backend before we establish the next launch baseline. Not P0: no incident, exploit, secret exposure, or local Assay failure is established. The ARM Mac host run does not exercise the SSE2 backend and is not a regression test for this defect. Do not label the finding a newly discovered cryptographic weakness or claim every x86 machine is affected.
Smallest fix / DoD
- In an owned worktree, update the lock to fixed chacha20 0.10.2; inspect the dependency delta and avoid unrelated upgrades or removing
--locked. - Verify the workspace and generated/published-package lock resolve the corrected dependency through the production route; preserve checksums and release reproducibility.
- Run affected evidence/core/MCP checks, formatting, clippy, security gates and required exact-head CI. Confirm x86 build coverage; do not call a green ARM run proof of the SSE2 fix.
- Obtain one independent exact-head review; do not bypass any required full-lane proof triggered by Cargo.lock.
- Record the corrective release disposition. Existing v5.5.1 published artifacts are immutable and remain on the old dependency; a main-only update does not repair them. Assess a patch release before the September production launch and bind host proof to whichever release is actually claimed.
The current v5.5.1 host acceptance work may continue as explicitly version-scoped evidence. It must not silently become proof for a later corrective release.
Activity
Rul1an commentedon Aug 31, 2026
#2728 candidate handoff
Next: inspect hosted results; obtain independent exact-head review; dispose actionable findings; require all required checks and accepted proof; land through safe_merge only then. If main advances, re-pin and follow the exact-head review carry rules, not an informal approval transfer.
Rul1an commentedon Aug 31, 2026
Closed on main; corrective publication still required
PR #2729 merged at 2026-08-31T19:35:20Z as
7b0e7818c38a3f36fe0f12360ad5174763d0cb98. Candidatebd8b7697db87bf1fb187a841bd489cc688666dfcand merge have identical treefb8836463f3c0667b41209ac8dd0b7bdc8318c37.Release disposition: prepare v5.5.2 to deliver the repaired locked dependency, tracked in #2667. No tag or new release exists from this merge. Published v5.5.1 remains unchanged. Keep its installation pin until the new assets/packages/attestations are verified, then measure final Claude/Codex launch acceptance on that published patch.
Learning: a successful ARM installation of a yanked locked dependency is not enough for a supported-x86 launch baseline. Inspect the upstream yank reason, normal/build dependency route, generated package lock, and actual fixed source before selecting the minimal change. Review and attested proof bind the candidate; the consumer workflow's trusted-main SHA is a separate provenance role.