You are talking about this?
https://chromium.googlesource.com/chromiumos/docs/+/master/fuzzing.md#adding-a-seed-corpus

Re #1: Yeah, the zip file method.

I'm in favor of getting rid of it since it isn't even easy on ChromeOS and Mike doesn't like having the binary files

But on second thought, it might be worth seeing what Abhishek (OOO until the 17th) thinks about this before going through with it.

I've spoken to inferno and the rest of my team. I don't think we should remove seed corpus if we can improve it on Chrome OS.

There are some problems with uploading directly to the corpus:
1. testcase can be pruned from corpus, so if code regresses and a testcase can catch it, it may not stay in the corpus but would stay in the seed corpus.

2. (in some cases) we can see what users put in seed corpus in code review so they can't give the fuzzer garbage.

We also have a feature called static corpus where the directory in the corpus $fuzz_target_static is never pruned and files are periodically copied into the real corpus. I can document this. This solves issue 1 but not  issue 2 .

The binary file thing is a big problem though. One thing we do in Chrome that makes it less of an issue is the build system actually zips directories instead of copying a hardcoded zip, which I think isn't a great solution for anyone.

One way to solve the binary file problem would be to create the zip of the corpus entries in the ebuild compile step. That way changes to the corpus can be reviewed and show up in version control in a way that makes sense. The corpus entries will still be binary files, but changing one corpus entry wouldn't create a duplicate of the entire zip in the git history.

The *current* fuzzer install step allows creating a corpus from a source directory i.e. no zip file needs to be created by user e.g. https://cs.corp.google.com/chromeos_public/src/third_party/chromiumos-overlay/chromeos-base/cryptohome/cryptohome-9999.ebuild?l=123.
But it does not remove the problem that the files in the corpus directory can themselves be binary e.g. pdfs etc.

Alternate option will be to push the seed corpus to gs:// which avoids the problem of copying the file to source repos.

vapier@, since the clusterfuzz team wants to keep the option of installing seed corpus in ebuild, can copying to gs://chromeos-localmirror/distfiles/ be considered an acceptable solution?