fuzz: route lookup and header finalization fuzzer.

[htuch]

This was a pretty easy small test to add to gain coverage over all route resolution and header
finalization. Automatically generated corpus from //test/common/router:config_impl_test. To regenerate the corpus:

bazel run //test/common/router:config_impl_test \
     --test_env="ROUTE_CORPUS_PATH=$PWD/test/common/router/route_corpus"

Risk level: Low
Testing: Corpus coverage of 72.4% for config_impl.cc.

Signed-off-by: Harvey Tuch htuch@google.com

[htuch]

@mattklein123 I can't say I'm a fan of checking in a corpus this massive, even though it is automatically generated and we have instructions for regenerating it in the PR. The main issue I see in general is that corpus files will require care and feeding as APIs evolve (in particular here, where there is a wide API surface included and we know there will be churn over time).

An alternative is that I keep this PR sans the checked in corpus, and do the generation action as an explicit bazel run step in the oss-fuzz Docker image. This will be problematic though when we integrate with our internal fuzzers, which are Bazel driven.

Possibly could figure out something with a genrule, but this won't help in oss-fuzz land, since oss-fuzz only uses Bazel to build, then scrapes out the contents of the Bazel cache for the final link and execution outside of Bazel.

Thoughts?

[mattklein123]

An alternative is that I keep this PR sans the checked in corpus, and do the generation action as an explicit bazel run step in the oss-fuzz Docker image. This will be problematic though when we integrate with our internal fuzzers, which are Bazel driven.

Sorry I don't follow this. If it's a bazel step, why wouldn't it work with the internal fuzzers?

Possibly could figure out something with a genrule, but this won't help in oss-fuzz land, since oss-fuzz only uses Bazel to build, then scrapes out the contents of the Bazel cache for the final link and execution outside of Bazel.

Still confused why this wouldn't work. Couldn't we have a scrip that runs that puts the files in the right place?

[htuch]

If it's a bazel run step as written today, writing files outside of the sandbox, it doesn't integrate properly with the normal build dependency graph, it's a separate shell invocation rather than a Bazel target.

I'll take a look to see if our internal corpus inputs can take a genrule as a dependency, if that's the case, we could always do a separate bazel step in the oss-fuzz Docker image to invoke the genrule and scrape stuff out of the cache. It's a bit icky; this is the first fuzz test where we would have special case logic in the Docker image.

[htuch]

@mattklein123 I've removed all of the corpus except a single file and left a TODO to figure out the genrule, this will let us get started with adding this test into internal/external fuzz frameworks and we can iterate from there.

[mattklein123]

I'm sorry you weren't able to pad your GH stats as much. 😉