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`

Abierto
  • ¿Algo no está bien?
#288 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
30/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
c, python
Área
build-system, ci-cd, testing-qa

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Python
Estrellas
4
Forks
1
Merge medio
10 h 41 min
PR fusionados (30 d)
79

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de cpp-best-practices/project_validator

Todos los issues de cpp-best-practices/project_validator

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.