fuzz: keep the fuzz corpus from one scheduled run to the next
Los mantenedores suelen responder en 4 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 68/100
Línea de trabajo
Lee .github/workflows/fuzz.yml y el contenido actual de fuzz/seeds/; la issue recomienda minimizar periódicamente el corpus de fuzzing con cargo fuzz cmin y hacer commit del resultado. Primero comprueba cómo ejecuta el workflow los objetivos de fuzzing y cómo están organizadas las semillas. Se considera terminado cuando el workflow sigue sin caché y un cambio revisado actualiza el corpus incluido en el repositorio.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What is wrong
Each Fuzz run starts from the committed seeds in fuzz/seeds and discards the corpus it builds. @robinnsc found on #798 that five of the six targets were still finding new coverage in the last second of the 60-second pull request run (comment). The 600-second daily run starts from the same seeds each day, so most of each run covers the same inputs as the run before.
Where
.github/workflows/fuzz.ymlfuzz/seeds/
What to change
Two options:
- An Actions cache of the corpus that only the scheduled job writes, and that pull request runs do not restore. The Fuzz workflow uses no cache, and the release workflows leave the Actions cache out on purpose because of the CodeQL cache-poisoning query. A pull request workflow can restore a cache that a run on
mainwrote, so any pull request could read the cached corpus. - A corpus that a maintainer minimizes with
cargo fuzz cminand commits tofuzz/seedsat intervals, in a pull request that gets the same review as any other change.
Recommendation
Option 2. The workflow stays free of caches, and a reviewer sees each change to the corpus.
- Lenguaje dominante
- Rust
- Estrellas
- 517
- Forks
- 60
- Merge medio
- 5 d 4 h
- PR fusionados (30 d)
- 76
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de ExtendDB/extenddb
-
ci:stability sqlite
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
Los mantenedores suelen responder en 4 días
-
check-cassandra-catalog-lock: a refused migrate changed a keyspace that held only the lock rowAbiertobackend:cassandra ci:stability
Dificultad 2/5 1-3 horas Aptitud para principiantes 84/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 64/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 4 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 4 días
Todos los issues de ExtendDB/extenddb
Issues similares
-
bug i18n priority: medium ui
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
storytold/craft-anything#983 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
`swf` upgrade to 0.4.0Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Dinnerbone/Rascal#91 · 2 reacciones ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
higress-group/HiRoute#405 ·
Los mantenedores suelen responder en 1 día
-
rust_analyzer flycheck: no CLI way to enable clippy from `check.overrideCommand`Posiblemente ocupada @TrapsterDK la tomó hoy. Abiertoneeds-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
bazelbuild/rules_rust#4392 ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día