chore(deps): move off a yanked chacha20 and fail on the next one (R18) - #51
Merged
Merged
Conversation
The key is out of the working tree, verified before it was moved. The half of the suggestion aimed at release/publish.sh does not apply: that script signs nothing, it dispatches publish-index.yml, which is the only thing that signs and which verifies its own signature against the committed public key on every run. So what sat in the tree was the backup rather than the thing that signs, which is the worse fact. The .gitignore comment saying the key belongs in Actions secrets 'and nowhere else' is corrected — that reading is how a machine ends up holding the only backup in a directory git clean sweeps.
cargo update -p chacha20 moves 0.10.1 to 0.10.2 and touches two lines of Cargo.lock. hickory does not move: the yanked version had a sibling inside the same ^0.10 that rand 0.10 already accepts. Why it was yanked was established rather than assumed, and did not need the network. chacha20's own CHANGELOG for 0.10.2 says the SSE2 backend used an SSE4.1 intrinsic in the RNG and legacy variants, and both versions are still in the local registry cache, so it is checkable: 0.10.1's src/backends/sse2.rs calls _mm_extract_epi32 at :54 and :133, an SSE4.1 intrinsic, and 0.10.2's calls none. That makes it a crash rather than a wrong answer, which is why RustSec carries no advisory. Backend selection is runtime CPUID over avx512, avx2 and sse2, and nothing in it tests SSE4.1; on x86-64 SSE2 is baseline and SSE4.1 is not, so a CPU with neither AVX2 nor SSE4.1 picks the SSE2 backend and executes an instruction it does not have. It reaches this workspace through hickory-proto -> rand 0.10 -> chacha20, which is where DNS message ids come from, so mixengined's DNS server would abort on a pre-2008 x86-64. No CI runner is that old, which is why the yank was the only evidence there was. yanked is now deny rather than warn, R9's ratchet for R9's reason. This makes the build depend on somebody else's action, which the duplicate check does not: a yank needs only an upstream author, so master can go red on a day nobody touched it. Accepted rather than overlooked, argued at the setting, and the repair is one line. Watched failing first: the new level against the old lock exits 1 naming chacha20.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
cargo update -p chacha20moves 0.10.1 → 0.10.2 and touches two lines ofCargo.lock.hickorydoes not move: the yanked version had a sibling inside the same^0.10thatrand0.10 already accepts.Why it was yanked was established rather than assumed, and did not need the network.
chacha20's own CHANGELOG for 0.10.2 (2026-08-27): "Fixed: Use of SSE4.1 intrinsic inSSE2 backend of RNG and legacy (64-bit counter) variants". Both versions are still in the
local registry cache, so it is checkable rather than quoted: 0.10.1's
src/backends/sse2.rscalls_mm_extract_epi32at:54and:133— an SSE4.1intrinsic — and 0.10.2's calls none.
So it is a crash, not a wrong answer, which is why RustSec carries no advisory for it.
Backend selection is runtime CPUID over
avx512,avx2andsse2, and nothing in thatdispatch tests SSE4.1. On x86-64, SSE2 is baseline and SSE4.1 is not, so a CPU with
neither AVX2 nor SSE4.1 picks the SSE2 backend and executes an instruction it does not
have:
SIGILL.It reaches this workspace through
hickory-proto→rand0.10 →chacha20, which iswhere DNS message ids come from — so
mixengined's DNS server would abort on a pre-2008x86-64. No CI runner is that old, which is exactly why nothing was ever seen and why the
yank was the only evidence there was.
yankedis now"deny", R9's ratchet for R9's reason. This makes the build depend onsomebody else's action, which the duplicate check does not: a new duplicate needs a
change here, a yank needs only an upstream author, so
mastercan go red on a day nobodytouched it. That is accepted rather than overlooked, argued at the setting, and the repair
is one line. Watched failing first: the new level against the old lock exits 1 naming
chacha20.CI: all 10 jobs green on the first run,
lintincluded.