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>
9 lines
252 B
Rust
9 lines
252 B
Rust
#![no_main]
|
|
use libfuzzer_sys::fuzz_target;
|
|
|
|
fuzz_target!(|data: &[u8]| {
|
|
if let Ok(s) = std::str::from_utf8(data) {
|
|
// Fuzz TOML config parsing — silently discard invalid input
|
|
let _ = toml::from_str::<toml::Value>(s);
|
|
}
|
|
});
|