HTTP parser fuzz regression workflow

The runtime-security workflow starts with six HTTP/JSON seeds generated by scripts/seed-http-fuzz-corpus.sh. That script also copies every *.seed file in tests/fuzz-corpus/ into the temporary libFuzzer corpus. The deterministic ASan/UBSan fallback replays the same supplied corpus before running its mutations.

Both compiler commands in scripts/fuzz-runtime.sh include -fno-sanitize-recover=undefined, so UBSan findings terminate the fuzz process. tests/fuzz-regression-pipeline.sh builds and runs a signed-overflow probe and fails if the probe continues after the diagnostic. The probe verifies the fatal setting locally; the Ubuntu GitHub Actions workflow still needs a successful hosted run before this is treated as a verified release gate. The local macOS fallback is not a substitute for the hosted Linux libFuzzer job.

When a CI run finds a crash:

1. Download the yaza-http-parser-fuzz-findings artifact from the failed workflow run.

2. Reproduce the finding locally and minimize the input with the same parser harness.

3. Review that the input is a useful regression case and contains no secrets or unrelated data.

4. Promote the reviewed input into the source tree:

   sh scripts/promote-http-fuzz-crash.sh /path/to/minimized-input

The command rejects symlinks and inputs at or above the 65,536-byte parser limit. It stores the exact bytes under a SHA-256-derived name in tests/fuzz-corpus/; repeating the command for the same input is safe. Commit the resulting seed so both future hosted fuzz runs and the local fallback replay it.

Crash artifacts are not promoted automatically. Review is required before a fuzz input becomes a permanent test fixture.

← Kembali ke semua dokumentasiVersi dan status rilis →