Zig: a library with no product binary is asked for a ReleaseSafe build; an AFL packaging shim is a C fuzz target; setup-zig without `version` installs build.zig.zon's minimum_zig_version; `zig build fuzz` / `zig build test --fuzz`

Aperta
  • Qualcosa non va?
#288 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
30/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c, python
Ambito
build-system, ci-cd, testing-qa

Direzione di ricerca

Start in ecosystems/zig.py, where _EXECUTABLE matches any addExecutable call and _read_programs treats that as a binary, so library build.zig files that only build examples or benchmarks wrongly pass the hardening check. The C/C++ fuzz-testing check also counts a comment-only __AFL_LOOP in pkg/afl++/afl.c as a fuzz target. Reproduce each with a minimal build.zig or .c fixture before changing anything. The Zig platform-matrix and fuzz gaps need a design decision first, so this is not a good first pick.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

http.zig and libxev: hardening FAIL "release builds drop Zig's safety checks: no ReleaseSafe build" although the only addExecutable calls build examples and benchmarks (a library has no binary to harden → SKIP). ghostty: fuzz-testing counts its AFL++ packaging shim (a manual expansion of AFL's macros) as a C/C++ fuzz target. zig-clap, zls, libxev, ghostty: "1 Zig version (default)" while mlugg/setup-zig with no version installs build.zig.zon's minimum_zig_version. tigerbeetle: fuzz-testing SKIPs "not applicable to Zig" though Zig projects fuzz with zig build fuzz and, since 0.14, zig build test --fuzz / std.testing.fuzz.

Evidence from the corpus audit

karlseguin/http.zig (also mitchellh/libxev) / hardening
  • kind: FALSE_POSITIVE
  • actual: FAIL: release builds drop Zig's safety checks: no ReleaseSafe build
  • expected: SKIP: "a library has no binary to harden" — the only addExecutable calls build the examples (and, in
    libxev, the benchmarks).
  • evidence: http.zig build.zig:81-83: for (examples) |ex| { / const exe = b.addExecutable(.{ / .name = ex.name,
    with .file = "examples/04_action_context.zig" entries at :70-78; libxev build.zig:194 ("src/bench/{s}" at
    :197-200), :244 and :259 ("examples/{s}"). Validator: ecosystems/zig.py:_EXECUTABLE = re.compile(r"\baddExecutable\s*\(") and _read_programs -> any match means "executable".
  • repro: build.zig whose only addExecutable has .root_source_file = b.path("examples/x.zig").
  • confidence: medium
ghostty-org/ghostty / fuzz-testing
  • kind: FALSE_POSITIVE
  • actual: FAIL: C/C++: fuzz targets in 1 file(s), but no CI configuration runs a fuzz target binary ...
  • expected: "no fuzz targets found" for C/C++: the one match is Ghostty's packaging shim for AFL++ (a manual expansion
    of AFL's macros), not a product fuzz target.
  • evidence: pkg/afl++/afl.c:14: // expand the AFL macros (__AFL_INIT, __AFL_LOOP, __AFL_FUZZ_INIT, etc.) and;
    :102: // Manual expansion of __AFL_LOOP(UINT_MAX) — persistent mode loop. (the only file matching
    LLVMFuzzerTestOneInput|__AFL_LOOP outside .git).
  • repro: a .c file whose only __AFL_LOOP is in a comment.
  • confidence: low
Hejsil/zig-clap (also zls, libxev, ghostty) / platform-matrix
  • kind: UNSUPPORTED
  • actual: FAIL: CI covers ... 1 Zig version(s) (default)
  • expected: n/a (gap): mlugg/setup-zig with no version input installs the minimum_zig_version of build.zig.zon,
    so "default" is a known version the validator could read from the manifest.
  • evidence: .github/workflows/main.yml:14-16: - uses: mlugg/setup-zig@v2 / with: / cache-key: ${{ matrix.optimize }}
    (no version); build.zig.zon:4: .minimum_zig_version = "0.18.0-dev.954+60635c2bd",.
  • repro: unclear (tool semantics)
  • confidence: low
tigerbeetle/tigerbeetle / fuzz-testing
  • kind: UNSUPPORTED
  • actual: SKIP: not applicable to ... Zig
  • expected: n/a (gap): Zig projects fuzz with a build step (zig build fuzz) and, since Zig 0.14, zig build test --fuzz / std.testing.fuzz; the profile knows no Zig fuzzer, so TigerBeetle's fuzzers and VOPR are invisible.
  • evidence: build.zig:168: .fuzz = b.step("fuzz", "Run non-VOPR fuzzers"),; :440-441:
    // zig build fuzz -- --events-max=100 lsm_tree 123 / build_fuzz(b, .{; :646:
    build_ci_step(b, step_ci, .{ "fuzz", "--", "smoke" }, ...). Docs: docs/ecosystems/zig.md "no ... fuzzer ... the
    validator knows reads Zig".
  • repro: unclear (tool support)
  • confidence: low

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Lingua principale
Python
Stelle
4
Fork
1
Merge medio
10h 41m
PR unite (30g)
79

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cpp-best-practices/project_validator

Tutte le issue di cpp-best-practices/project_validator

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.