bobluppes / bobluppes/graaf

Add sanitizer (ASan/UBSan/TSan) and fuzz testing to CI

Abierto
#326 0 comentarios 0 reacciones 0 asignados Ver en GitHub
Lenguaje dominante
C++
Estrellas
413
Forks
67
Merge medio
7 h 24 min
PR fusionados (30 d)
53

Descripción

## Summary

CI does not run the test suite under any sanitizer (ASan, UBSan, TSan) or with any fuzz testing. The only dynamic-analysis signal currently produced is line/branch coverage.

## Current state

- Neither [.github/workflows/main-ci.yml](../blob/main/.github/workflows/main-ci.yml) nor [.github/workflows/pull-request.yml](../blob/main/.github/workflows/pull-request.yml) pass any `-fsanitize=...` flags, and `CMakeLists.txt` has no `ENABLE_SANITIZER`-style option (compare to the existing `ENABLE_COVERAGE` option used for the coverage job).
- There is no fuzzing harness anywhere in the repo (e.g. nothing under `test/` or a dedicated `fuzz/` directory targets libFuzzer/AFL-style entry points), despite the library including a hand-rolled DOT-format parser/serializer ([include/graaflib/io/dot.h](../blob/main/include/graaflib/io/dot.h)) that is a natural candidate for fuzzing since it processes external, potentially untrusted input.
- Both CI workflows only build in `Debug` with plain compiler flags; there's no `RelWithDebInfo`+sanitizer configuration exercised anywhere.

## Why this matters

95%+ line coverage (the project's own [codecov.yml](../blob/main/codecov.yml) target) tells you code was *executed*, not that it's free of undefined behavior, memory errors, or data races — those require dedicated tooling. For a header-only library that will be compiled directly into many different downstream binaries (rather than shipped as a pre-built, independently-hardened artifact), catching UB/memory issues before release is more important than for a typical application, since every consumer inherits any latent bug at their own optimization levels and platforms. Given the library ships a hand-written parser that accepts external input, this is a concrete, not just theoretical, risk area.

## Suggested resolution

- Add a CMake option (e.g. `ENABLE_SANITIZER=address|undefined|thread`) that adds the corresponding `-fsanitize=...` flags to the test build.
- Add CI jobs that build and run the existing test suite under ASan+UBSan, and separately under TSan.
- Add a small libFuzzer (or similar) harness for the DOT parser and run it for a bounded time in CI (or as a periodic/scheduled job), seeded with the existing test fixtures.

## Acceptance criteria

- [ ] CI runs the test suite under ASan+UBSan on every PR (or at minimum on merges to `main`).
- [ ] CI runs the test suite under TSan (relevant once/if thread-safety guarantees are documented, see the related issue).
- [ ] A fuzz target exists for the DOT parser and runs regularly, with any findings triaged.

Guía de contribución

Abrir la guía de contribución

Línea de trabajo

The issue points to .github/workflows/main-ci.yml and .github/workflows/pull-request.yml for CI, and CMakeLists.txt for build configuration. The DOT parser is in include/graaflib/io/dot.h. Start by adding an ENABLE_SANITIZER CMake option, then integrate sanitizer flags into the CI workflows. For fuzzing, create a libFuzzer harness in a new directory like fuzz/. Done looks like CI jobs passing with sanitizers enabled and a fuzz target running.

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

Evaluación

Stack tecnológico
cmake, cpp, github-actions
Área
ci-cd, security, testing-qa
Tipo de issue
Nueva funcionalidad
Dificultad
4/5
Tiempo estimado
3-5 días
Estado de actividad
Activo
Claridad
Bien especificado
Aptitud para principiantes
45/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.