Need a way to distinguish non C/C++ projects

[Dor1s]

This is blocking #2714.

Let's look at Go projects as an example:

1. various build configs are intentionally not supported and should not be used (only asan + libfuzzer should be used)

2. coverage is not supported; when it becomes available, it will likely need a distinguisher (e.g. to run a different script, or branch the behavior somehow else)

3. srcmap for go projects should also look for repos in $GOPATH/src, but there is no value in recording these for non Go projects

There is a workaround in GCB coverage script:

oss-fuzz/infra/gcb/build_and_run_coverage.py

Line 64 in e82397b

if GO_FUZZ_BUILD in fh.read():

but it's hacky and won't last long, as project with ideal integration will not work with it.

I'm proposing a new attribute in project.yaml file to reflect the language being fuzzed. It can be called either language or runtime or anything else.

Having that would let us be more flexible and less hacky on the infra side, as we'll be able to run more specific scripts and commends for different languages.

I expect this to be handy when/if we add more languages too. Even now, for a project written in Rust, the workflow differs from C/C++ and also creates some friction. If we could easily know that a certain project is in Rust, we would treat it differently from the infra side (e.g. allow to use $LIB_FUZZING_ENGINE_DEPRECATED, or even rename it to $LIB_FUZZING_ENGINE to avoid being weird).

Thoughts?

//cc @oliverchang @jonathanmetzman explicitly

[oliverchang]

+1 to adding language to project.yaml

[jaqx0r]

I'm impacted by this, and before I filed the bug above I had assumed that I had failed to configure something in the project.yaml correctly to enable or disable coverage, i.e. next to the sanitizers list that you need to do for Go anyway. If coverage was an explicit santitizer, or a separate option, that would be easy to understand from this user's perspective.

sanitizers:
 - address
 - coverage

or

santiziers:
  - address
coverage: no

[jonathanmetzman]

Slight alternative idea: a field called info where one can put things like rust golang or any other future attribute we may want to set

[oliverchang]

Slight alternative idea: a field called info where one can put things like rust golang or any other future attribute we may want to set

I think we should avoid such "catchall" fields. There's not much benefit that I can see (very slightly easier to add something new) and it's much better to be explicit.

[Dor1s]

Thanks for your input, folks!