OPU-33: decodeRe's hex alternative matched an ENCODE, not a decode - #101
Merged
Conversation
Found during an FP sweep of the OPU-32 markers against real-world install
scripts (esbuild, edge-js, ntsuspend, -fail-on-eligible). All three new
OPU-32 markers came back clean. The sweep's one hit was VC-002e on esbuild,
tracing to decodeRe, pre-existing since the initial public release
(confirmed by git blame and reproducing against the pre-OPU-32 binary).
decodeRe's hex alternative was a bare ['"]hex['"]\s*\) — matched the
literal string hex") anywhere. esbuild's real install.js computes
crypto.createHash("sha256").update(bytes).digest("hex") to verify a
downloaded binary's checksum: an ENCODE, not a decode. The bare literal
couldn't distinguish that from Buffer.from(x, 'hex'), a genuine decode.
Tightened to the same context-required shape the base64 alternative in the
same regex already used. No existing test depended on the old bare shape.
The repo's own D-25 esbuild fixture was a faithful reduction that didn't
include this real line — extended it with the actual checksum-verify idiom
so the existing regression test exercises the real FP directly, rather than
adding a parallel synthetic test that would prove less.
Mutation-proven: reverting the regex fails both the new negative tests and
the now-faithful esbuild fixture test; restore green. Live end-to-end: the
sweep's cited shape now scores exit 2 with only legitimate VC-002b (real
network egress) firing. Full suite green (34 packages), -race clean.
Records D-125.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PLd1shywzWPsLgkpLxEyPj
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
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.
The finding
An FP sweep of the OPU-32 markers against real-world install scripts (esbuild, edge-js, ntsuspend, run under
-fail-on-eligible) came back clean — none of the three new OPU-32 markers fired anywhere, including on esbuild, the exact package D-25/D-28's own design comments already cite as the FP case to avoid.The sweep's one hit was VC-002e on esbuild, and it traced to
decodeRe(internal/installsurface/analyze.go) — pre-existing since the initial public release, confirmed here bygit blame(e3dd322) and by independently reproducing the identical finding against the pre-OPU-32 binary.decodeRe's hex alternative was a bare['"]hex['"]\s*\)— it matched the literal stringhex")anywhere in a file. esbuild's realinstall.jscomputescrypto.createHash("sha256").update(bytes).digest("hex")to verify a downloaded binary's checksum: an ENCODE (bytes → hex string, for display/comparison — the thing a security-conscious installer should do), not a decode. The bare literal couldn't distinguish that fromBuffer.from(x, 'hex'), a genuine decode.The fix
Tightened to the same context-required shape the base64 alternative in the same regex already used:
Buffer\.from\s*\([^)]*['"]hex['"]|from_?hex|hex::decode— mirroring base64'sBuffer.from(...,'base64')plus the Rust-style naming alternatives already present (base64::decode/base64::engine). No existing test depended on the old bare shape (verified before touching it).The repo's own D-25 esbuild regression fixture (
esbuildLikeInstallJS) was a faithful reduction that didn't include this real line — extended it with the actual checksum-verify idiom so the existing regression test (TestEsbuildInstallerNotObfuscated) exercises the real FP directly, rather than adding a parallel synthetic test that would prove less than it claimed.Validation
opu33_test.go): hex ENCODE (digest/toString) no longer reads as obfuscation; genuine hex decode (Buffer.from,from_hex,hex::decode) still does.-raceclean,go vetsilent,gofmtno diffs.Files
internal/installsurface/analyze.go— tighteneddecodeRehex alternative.internal/installsurface/esbuild_regression_test.go— enriched fixture with the real checksum-verify idiom.internal/installsurface/opu33_test.go— new tests.docs/DECISIONS.md— D-125.🤖 Generated with Claude Code
Generated by Claude Code