zeroclaw

harald/zeroclaw

Fork 0

Commit graph

Author	SHA1	Message	Date
Alex Gorevski	d407eb61f0	test(fuzz): add webhook, provider response, and command validation fuzz targets Add three new fuzz targets expanding coverage from 2 to 5 targets: - fuzz_webhook_payload: fuzzes webhook body JSON deserialization - fuzz_provider_response: fuzzes provider API response parsing - fuzz_command_validation: fuzzes security policy command validation Addresses audit findings for critical fuzz coverage gaps in gateway, provider, and security subsystems. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>	2026-02-19 13:19:56 -08:00
Alex Gorevski	217a700bfa	ci: add fuzz testing workflow and harnesses (#629 ) 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>	2026-02-17 15:12:08 -05:00

Author

SHA1

Message

Date

Alex Gorevski

d407eb61f0

test(fuzz): add webhook, provider response, and command validation fuzz targets

Add three new fuzz targets expanding coverage from 2 to 5 targets:
- fuzz_webhook_payload: fuzzes webhook body JSON deserialization
- fuzz_provider_response: fuzzes provider API response parsing
- fuzz_command_validation: fuzzes security policy command validation
Addresses audit findings for critical fuzz coverage gaps in gateway,
provider, and security subsystems.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

2026-02-19 13:19:56 -08:00

Alex Gorevski

217a700bfa

ci: add fuzz testing workflow and harnesses (#629 )

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>

2026-02-17 15:12:08 -05:00

2 commits