[juan-malbeclabs]

Cargo.lock on main is one Cargo refuses to use, and it has been blocking every GHCR image publish since 2026-09-08:

error: cannot update the lock file /src/Cargo.lock because --locked was passed to prevent this

Summary

• Unblocks the doublezero-edge-connect image publishes. :mainnet-beta is still the 2026-09-07 build, pinned to the 0.38.0 client base — it missed the doublezero:mainnet-beta-0.39.0-1 base published on 09-10, and the daily poll backstop fails for the same reason.
• Two ambiguous refs: rand 0.9.4 and rand_chacha 0.9.0 name a bare "rand_core" while both rand_core 0.9.5 and 0.10.1 are locked. Cargo cannot resolve a bare name against two versions, so it must rewrite the lock — which --locked forbids.
• Six orphan entries reachable from nothing: block-buffer 0.10.4, cpufeatures 0.2.17, crypto-common 0.1.7, digest 0.10.7, generic-array 0.14.7, version_check 0.9.5.
• No reachable package changes version or checksum. The whole diff is the six removed orphans plus the dependency names they had made ambiguous.

Why it happened

Six Dependabot PRs merged within ~30 seconds on 2026-09-07 without being rebased onto each other. #85 (ed25519-dalek 2.2.0 → 3.0.0) resolved a lock with a single rand_core and dropped the digest 0.10 chain; #81 (rust-minor-patch group, lock-only) was resolved against the pre-upgrade tree. Each lock was correct against its own base, and git merged them line by line with no conflict.

Nothing caught it because rust CI runs cargo build/clippy/test --workspace without --locked and silently re-resolves. The Dockerfile's cargo build --release --locked is the only thing that enforces the lock, so the first symptom was a failed image publish days later rather than a red CI run. A follow-up adds --locked to rust.yml; requiring branches to be up to date before merging would stop two independently-resolved locks merging cleanly again.

Testing Verification

• Reproduced the failure on main at e258968: cargo metadata --locked exits 101 with the message above; with this lock it exits 0.
• cargo build --workspace --release --locked succeeds.
• Audited the lock graph from the three workspace roots: 0 ambiguous refs and 0 orphans, down from 2 and 6.
• Merging this to main triggers release.docker.edge-connect.yml, which republishes :testnet, :mainnet-beta and devnet :latest against the current bases — confirm afterwards that :mainnet-beta's org.opencontainers.image.base.digest matches doublezero:mainnet-beta-0.39.0-1.

[juan-malbeclabs]

Superseded by #151, which has been green and awaiting review since 2026-09-07.

I opened this before checking the open PRs. #151 already contains the identical lock regeneration — it removes the same six orphan entries (block-buffer 0.10.4, cpufeatures 0.2.17, crypto-common 0.1.7, digest 0.10.7, generic-array 0.14.7, version_check 0.9.5) and qualifies the two bare "rand_core" refs as rand_core 0.9.5 — and bumps chacha20 0.10.1 → 0.10.2, which is the yanked crate currently failing cargo-deny on every PR in this repo (including this one and #154).

Verified against #151's head (91e8ec5): 0 ambiguous refs, 0 orphans, chacha20 0.10.2. So merging #151 alone unblocks the image publishes described in #155 and turns cargo-deny green. Nothing here to merge on top of it.