Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[dev.fuzz] all: tracking issue for release-blocking fuzzing work #47037

Open
2 of 21 tasks
katiehockman opened this issue Jul 2, 2021 · 0 comments
Open
2 of 21 tasks

[dev.fuzz] all: tracking issue for release-blocking fuzzing work #47037

katiehockman opened this issue Jul 2, 2021 · 0 comments

Comments

@katiehockman
Copy link
Task lists! Give feedback
Member

@katiehockman katiehockman commented Jul 2, 2021

This is the tracking issue for fuzzing-related work which must be done before fuzzing can be part of a standard release of the Go toolchain.

The current plan is to merge the fuzzing code into master once the tree opens in the fall of this year (2021).
This would make fuzzing available for Go 1.18.

The following is a list of release-blocking features (in no particular order):

  • Merge fuzzing into master, removing the default build tag (gofuzzbeta) currently in the dev.fuzz branch
  • Documentation describing which types are currently supported for fuzzing
  • A decision must be made on whether or not fuzzing will support generics, as adding this later would break backwards compatibility for existing fuzz targets
  • Minimization of interesting inputs
  • Implement better deduplication of interesting inputs so the ondisk corpus doesn't get too inflated
  • Fuzzing works with -race and -msan. It doesn't have to add a lot of additional value, but the go tool shouldn't break.
  • A decision must be made for how -cpu is used
  • A decision must be made on whether other tests run when -fuzz is set
  • A decision must be made on whether types can be converted when using f.Add and f.Fuzz (may decide to make this more strict for now)

The following is a list of nice-to-have features (in a rough order):

  • Don't store corpus in memory
  • Allow multiple fuzz targets to be run with a single go command
  • The mutators might be a bit too aggressive, and could be improved (#47090)
  • A tool that can convert binary files into the fuzz encoding file format
  • Deduplication of crashes
  • Support for -keepfuzzing (This is contingent on deduplication working first)
  • Support for fuzzing more builtin types, such as slices and arrays
  • Supporting dictionaries
  • Support for fuzzing structs
  • Prioritization of newly discovered interesting inputs, and perhaps some minimal work done on newly discovered interesting inputs.
  • Improved mutator - specifically one that uses other corpus entries while mutating
  • Supports a build mode which can generate a compiled binary to be run using libFuzzer

There are other issues with the 'fuzz' label which will also be release blockers once fuzzing is merged. Once the tree is open, the release blocker label will be used at that time.

Which items are in the "release-blocker" list and which are in the "nice-to-have" list may change over time, depending on user feedback, and new items may be added at any time as well.

/cc @golang/fuzzing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants