Repository: go
Issue: x/fuzzdata: new repository for fuzzing corpus data
Labels: NeedsDecision

### Summary

In #30719 and #30979, `dvyukov/go-fuzz` compatible fuzz functions were landed in:
* the standard library in [src/image/png/fuzz.go](https://github.com/golang/go/blob/master/src/image/png/fuzz.go)
* `golang.org/x` in [golang.org/x/image/tiff/fuzz.go](https://github.com/golang/image/blob/master/tiff/fuzz.go) 

The follow-up item in this issue here is to add a new `golang.org/x/corpus` repository to hold an example fuzzing corpus for portions of the standard library and x subrepos. This is to help with the exploration requested by the core Go team in discussion of the #19109 proposal to "make fuzzing a first class citizen". 

The name for the new corpus repo alternatively could be `golang.org/x/fuzz` or something else; some additional naming discussion below.

Note that this issue is at least currently intended to be solely about creating the repository itself, and this issue does not cover checking in any corresponding fuzzing corpus (which is likely to be a follow-up issue).

### Background

See the "Background" section of #30719 or https://github.com/golang/go/issues/19109#issuecomment-441442080.

### Additional Details

As part of the #19109 proposal discussion, there were multiple comments/requests from the core Go team asking to develop a better understanding of how a fuzzing corpus looks and behaves when it resides in a repository. For example, this March 2017 request in https://github.com/golang/go/issues/19109#issuecomment-289573239 from Russ:

> add fuzz tests to at least the x subrepos and maybe the standard library, so that we can understand the implications of having them in the source repos (including how much space we're going to spend on testdata/fuzz corpus directories

In the March 2017 proposal document in https://github.com/golang/go/issues/19109#issuecomment-285456008, @dvyukov proposed:

> For the standard library it is proposed to check in corpus into `golang.org/x/fuzz` repo.

`golang.org/x/fuzz` seems to be a very reasonable name. Two alternative possible names:

* `golang.org/x/corpus`
* `golang.org/x/fuzzcorpus`

Personally, I think `x/corpus` or `x/fuzzcorpus` might be more evocative than `x/fuzz` (e.g., someone might incorrectly think `x/fuzz` is where the fuzzing implementation or fuzzing functions live), but I do not have a strong opinion on the name and suspect others will have stronger opinions. Until there is additional feedback on the name, the rest of this comment here will use the term `golang.org/x/corpus`.

### Populating the corpus

The initial seeding of the corpus can likely come from https://github.com/dvyukov/go-fuzz-corpus for a given Fuzz function. If that happens, then right now, there would be two corpus directories populated: [go-fuzz-corpus/png/corpus](https://github.com/dvyukov/go-fuzz-corpus/tree/master/png/corpus) and [go-fuzz-corpus/tiff/corpus](https://github.com/dvyukov/go-fuzz-corpus/tree/master/tiff/corpus).  

In parallel, multiple people are making progress on integrating `dvyukov/go-fuzz` into oss-fuzz in google/oss-fuzz#36, google/oss-fuzz#2188, dvyukov/go-fuzz#213 and elsewhere. Most likely, it will make sense to periodically update the `golang.org/x/corpus` repo with the output from oss-fuzz (which otherwise by default is stored in a Google Cloud Storage bucket).

However, the exact mechanism of populating and updating `golang.org/x/corpus` repo I think can be discussed outside of this particular issue. (Reason: In general, it seems more tractable to make progress if things are broken down into more manageable discrete chunks of work, especially to break out into separate steps the things that must be done by someone on the core Go team, vs. could be done by someone from the broader community. This issue is focused on the creation of the repo, which presumably must be done by someone on the core Go team, whereas populating the corpus can be done by a greater range of people from the broader community in consultation with the core Go team).
 
I am of course happy to discuss anything here, and happy to be corrected if any of the above is different than how people would like to proceed.

CC @dvyukov @josharian @FiloSottile @bradfitz @acln0