217a700bfa
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> |
||
|---|---|---|
| .. | ||
| codeql | ||
| ISSUE_TEMPLATE | ||
| workflows | ||
| actionlint.yaml | ||
| CODEOWNERS | ||
| dependabot.yml | ||
| label-policy.json | ||
| labeler.yml | ||
| pull_request_template.md | ||