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`

Ouverte
  • Quelque chose ne va pas ?
#288 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
30/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
c, python
Domaine
build-system, ci-cd, testing-qa

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.