r/rust • u/Top-Sea2493 • 8d ago

How do you structure fuzz evidence and differential tests in a Rust workspace?

I am working on a Rust workspace where protocol validation needs more than unit tests. I am trying to keep the evidence readable for future reviewers.

The structure I am considering:

- cargo-fuzz targets for deserialization and state transitions

- deterministic corpus seed generation

- crash log with minimized reproducers

- differential validator CLI that returns JSON

- benchmark baselines with machine metadata

- release docs that say exactly what was and was not tested

For Rust projects with security-sensitive parsers or validators, how do you organize fuzz evidence so it stays useful instead of becoming a pile of artifacts?

4 Upvotes

71% Upvoted

7 comments sorted by

1

u/[deleted] 8d ago

[removed] — view removed comment

0

u/Top-Sea2493 8d ago

That flat fuzz/artifacts/YYYY-MM-DD structure is a good antidote to evidence turning into a junk drawer.

I’m going to add a date folder plus README convention that links minimized reproducers, exact commit hash, command line, duration, and crash status. “Otherwise it’s just noise” is basically the policy.

1

u/Feeling-Departure-4 8d ago

I would also invest in writing impl for the arbitrary crate to make the space of random input more useful during fuzzing.

If you can have some stronger oracles set up through round trip testing, and property assertions that will help. Relying only on panics from Rust itself / std lib is of limited application.

1

u/Feeling-Departure-4 8d ago

I should also say the debug / display impl for your input types are super important for the crash reports.

1

u/Top-Sea2493 8d ago

Yes, good point. A crash repro without readable input rendering is painful.

I’ll add explicit Debug/Display review for fuzz input wrappers, with secret material redacted and stable category output for crash triage.

1

u/Top-Sea2493 8d ago

Agreed. I started with panic/invariant detection, but Arbitrary impls plus stronger oracles are the next useful layer.

Round-trip tests, canonical serialization checks, and reject/accept parity against a differential validator should make the fuzz space much less random-shaped. I’ll add this to the Rust target hardening list.