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`

Offen
  • Stimmt etwas nicht?
#288 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
30/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
c, python
Bereich
build-system, ci-cd, testing-qa

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.