fuzz: keep the fuzz corpus from one scheduled run to the next

未关闭 适合新手
  • 哪里不对？
#862 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 4 天内回复

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
68/100
Issue 类型
功能
描述清晰度
描述清楚
活跃度
活跃
技术栈
github-actions, rust
领域
ci-cd, testing

调研方向

阅读.github/workflows/fuzz.yml和fuzz/seeds/的当前内容；该 issue 建议定期使用cargo fuzz cmin缩减模糊测试语料库，并提交结果。先检查 workflow 如何运行模糊测试目标，以及 seeds 如何组织。完成标准是 workflow 继续不使用缓存，并且经过审查的更改更新已提交的语料库。

由索引模型根据 Issue 内容生成。

描述

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.yml
  • fuzz/seeds/

What to change

Two options:

  1. 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 main wrote, so any pull request could read the cached corpus.
  2. A corpus that a maintainer minimizes with cargo fuzz cmin and commits to fuzz/seeds at 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.

主要语言
Rust
星标
517
派生
60
平均合并
5 天 3 小时
30 天内合并 PR
79

环境准备

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

ExtendDB/extenddb 的其他 Issue

查看 ExtendDB/extenddb 的全部 Issue

相似的 Issue

更多 Rust Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。