chore: make fuzz actually fuzz (DSPX-4903) - #4096
Conversation
|
Navigate logical layers of code changes, visualize relationships, and explore their blast radius. No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: ASSERTIVE Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: This review used your included allowance. Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe Makefile adds ChangesFuzz target workflow
Priority: ⬇️ Low Estimated code review effort: 2 (Simple) | ~10 minutes Change: Bug fix Suggested reviewers: Merge Risk: ⚪ Minimal · up to No actionable issue introduced by this change remains; the fuzz target's documented behavior matches its implementation. Architecture SummaryArchitecture risk: 🔵 Low · up to The change affects 2 systems. Changed systems: Architecture concerns Review detailsSystems and components
Before / after behavior
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. A rabbit finds the fuzzers’ trail Comment |
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
Previously stderr from 'go test -list' was discarded, so a package that failed to compile was treated as having no fuzz targets and 'make fuzz' could pass having fuzzed nothing. Abort with the errors visible instead, and skip testdata and vendor when discovering candidate packages. Signed-off-by: Dave Mihalcik <dmihalcik@virtru.com>
34caae5 to
bf58ec7
Compare
Benchmark results, click to expandBenchmark authorization.GetDecisions Results:
Benchmark authorization.v2.GetMultiResourceDecision Results:
Benchmark Statistics
Bulk Benchmark Results
TDF3 Benchmark Results:
|
|
Fixes DSPX-4903.
Problem
make fuzzhas never fuzzed anything.Without
-fuzz=<regexp>,go testtreats aFuzzXxxfunction as an ordinary test that replays only its seed corpus. No mutation, no coverage-guided exploration.-fuzztimeis silently ignored when-fuzzis absent:A 20-second budget returned in 0.3 seconds.
Two more defects in the same two lines:
-fuzztakes one package and one target per invocation.go test ./... -fuzz=...is rejected outright, so this needs a loop, not just an extra flag.sdkonly, missinglib/ocrypto'sFuzzUncompressECPubKey. The siblingtestandbenchtargets both iterate$(HAND_MODS).Change
Rewrites the target to discover every
FuzzXxxacross$(HAND_MODS)and run each one with-fuzz. Discovery is dynamic, so a new target is picked up without editing the Makefile. Agrepnarrows to candidate packages first, becausego test -listbuilds a test binary per package and nearly all of them have no fuzz targets.Discovery skips
testdataandvendor, and a failinggo test -list(e.g. a package that does not compile) aborts the run with its errors visible instead of being treated as "no targets" — otherwisemake fuzzcould pass having fuzzed nothing.Adds
FUZZTIME(default30s, per target) andfuzzto.PHONY, and documents the target inAGENTS.md— including the crasher workflow, which is a real footgun: Go writes a crasher totestdata/fuzz/<Target>/<hash>, and every later plaingo testreplays it as a seed, so committing one before its fix turns the whole suite red.No production code changes. No new fuzz targets, no seed-corpus additions.
Verification
All six targets are now discovered and fuzzed, in both modules:
make fuzz FUZZTIME=2sconfirms real fuzzing rather than seed replay:and a failing target propagates a non-zero exit (
make: *** [fuzz] Error 1).Heads-up: this makes
make fuzzfail onmaintodayWithin ~1 second of actually fuzzing,
FuzzReaderfinds a live panic:A ZIP64 size field ≥ 2^63 converts to a negative
int64atreader.go:173, passes the upper-bound-only check atreader.go:350, and reachesmake([]byte, negative).That bug is already fixed by #4043 / DSPX-4590 (in review), whose code comment describes this exact failure mode. It is deliberately not fixed here — this PR is the runner only. So
make fuzzwill fail onmainuntil DSPX-4590 lands. That is the target doing its job, and it is safe:make fuzzis not referenced anywhere in.github/, so nothing in CI depends on it and this cannot turn CI red.Wiring fuzzing into CI is intentionally out of scope; it needs corpus persistence and a triage story first, and should be its own ticket.
Testing notes
make fuzz FUZZTIME=2s— discovery, real fuzzing, non-zero exit on failure, all verified above.make test/make lintare unaffected.testdata/fuzzfiles.Summary by CodeRabbit
New Features
make fuzzto discover and run fuzz tests across supported packages, with a configurable run time.Documentation
make test, how to configure its run time, where Go stores crash cases, and how to preserve a crash case with its fix.