Problem: Security-critical parsing surfaces (config loading, tool
parameter deserialization) have no fuzz testing coverage. Malformed
inputs to these surfaces could cause panics, memory issues, or
unexpected behavior in production.
Solution: Add a weekly cargo-fuzz CI workflow with two initial
harnesses:
- fuzz_config_parse: fuzzes TOML config deserialization
- fuzz_tool_params: fuzzes JSON tool parameter parsing
The workflow runs each target for 300 seconds (configurable via
workflow_dispatch input), uses nightly Rust toolchain (required by
libfuzzer), and uploads crash artifacts for triage with 30-day
retention. Step summaries report pass/fail status per target.
Files added:
- .github/workflows/fuzz.yml (scheduled + manual dispatch)
- fuzz/Cargo.toml (fuzz crate manifest)
- fuzz/fuzz_targets/fuzz_config_parse.rs
- fuzz/fuzz_targets/fuzz_tool_params.rs
Testing: Validated YAML syntax and Cargo.toml structure. Fuzz
harnesses use standard libfuzzer-sys patterns. Actual fuzzing
will execute on first scheduled or manual CI run.
Ref: zeroclaw-labs/zeroclaw#618 (item 4 — Fuzz Testing)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
