build: make fuzz actually fuzz (DSPX-4903)

[dmihalcik-virtru]

Fixes DSPX-4903.

Problem

make fuzz has never fuzzed anything.

fuzz:
	cd sdk && go test ./... -fuzztime=2m

Without -fuzz=<regexp>, go test treats a FuzzXxx function as an ordinary test that replays only its seed corpus. No mutation, no coverage-guided exploration. -fuzztime is silently ignored when -fuzz is absent:

$ go test -run 'XXXNONE' -fuzztime=20s ./internal/zipstream/
ok  github.com/opentdf/platform/sdk/internal/zipstream  0.298s  [no tests to run]

A 20-second budget returned in 0.3 seconds.

Two more defects in the same two lines:

• -fuzz takes one package and one target per invocation. go test ./... -fuzz=... is rejected outright, so this needs a loop, not just an extra flag.
• Scope was sdk only, missing lib/ocrypto's FuzzUncompressECPubKey. The sibling test and bench targets both iterate $(HAND_MODS).

Change

Rewrites the target to discover every FuzzXxx across $(HAND_MODS) and run each one with -fuzz. Discovery is dynamic, so a new target is picked up without editing the Makefile. A grep narrows to candidate packages first, because go test -list builds a test binary per package and nearly all of them have no fuzz targets.

Adds FUZZTIME (default 30s, per target) and fuzz to .PHONY, and documents the target in AGENTS.md — including the crasher workflow, which is a real footgun: Go writes a crasher to testdata/fuzz/<Target>/<hash>, and every later plain go test replays 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:

==> lib/ocrypto . FuzzUncompressECPubKey
==> sdk . FuzzLoadTDF
==> sdk . FuzzNewResourceLocatorFromReader
==> sdk . FuzzNewAttributeNameFQN
==> sdk . FuzzNewAttributeValueFQN
==> sdk ./internal/zipstream FuzzReader

make fuzz FUZZTIME=2s confirms real fuzzing rather than seed replay:

fuzz: elapsed: 0s, gathering baseline coverage: 76/76 completed, now fuzzing with 18 workers

and a failing target propagates a non-zero exit (make: *** [fuzz] Error 1).

Heads-up: this makes make fuzz fail on main today

Within ~1 second of actually fuzzing, FuzzReader finds a live panic:

panic: runtime error: makeslice: len out of range
  readBytes(...)        reader.go:375
  ReadAllFileData(...)  reader.go:354

A ZIP64 size field ≥ 2^63 converts to a negative int64 at reader.go:173, passes the upper-bound-only check at reader.go:350, and reaches make([]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 fuzz will fail on main until DSPX-4590 lands. That is the target doing its job, and it is safe: make fuzz is 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.
• No Go code touched, so make test / make lint are unaffected.
• Any crashers produced during verification were removed; this branch adds no testdata/fuzz files.

[coderabbitai]

Warning

Review limit reached

Next included review available in 8 seconds.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: Repository UI

Review profile: ASSERTIVE

Plan: Advanced

Run ID: 8f8ae2aa-1615-429a-b52d-07b778387205

📥 Commits

Reviewing files that changed from the base of the PR and between 8eefa1b and 34caae5.

📒 Files selected for processing (2)

• AGENTS.md
• Makefile

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[github-actions]

Benchmark results, click to expand

Benchmark authorization.GetDecisions Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	245.657415ms

Benchmark authorization.v2.GetMultiResourceDecision Results:

Metric	Value
Approved Decision Requests	1000
Denied Decision Requests	0
Total Time	133.379653ms

Benchmark Statistics

Name	№ Requests	Avg Duration	Min Duration	Max Duration

Bulk Benchmark Results

Metric	Value
Total Decrypts	100
Successful Decrypts	100
Failed Decrypts	0
Total Time	469.554454ms
Throughput	212.97 requests/second

TDF3 Benchmark Results:

Metric	Value
Total Requests	5000
Successful Requests	5000
Failed Requests	0
Concurrent Requests	50
Total Time	58.99405566s
Average Latency	588.69756ms
Throughput	84.75 requests/second

[github-actions]

⚠️ Govulncheck found vulnerabilities ⚠️

The following modules have known vulnerabilities:

• otdfctl
• service
• tests-bdd

See the workflow run for details.

[github-actions]

X-Test Results

✅ go@main-main
✅ java@main-main
✅ js@main-main
✅ go@pull-4096-v0.9.0
bats-test-results
✅ js@main-pull-4096
✅ js@main-v0.9.0
✅ java@main-pull-4096
govulncheck-failure-1
✅ java@main-v0.9.0
✅ go@pull-4096-pull-4096
govulncheck-failure-8
opentdfplatformL13TYI.dockerbuild
cukes-report
✅ go@main-pull-4096
✅ go@pull-4096-main
✅ go@main-v0.9.0
govulncheck-failure-3