feat: Create fuzzer for R language parser

[terriko]

Description

cve-bin-tool has an existing fuzz testing setup which is based on Google Atheris. One of the areas it doesn't yet cover is the files used by the language list parsers. These are typically lists of 3rd party components/requirements written in a format to a specific packaging tool for a specific programming language. These may be lists of requirements generated by a human, or they could be generated by a tool.

This particular request is to fuzz the R language parser which uses renv.lock files, but I'll be filing requests for the other parsers as well. You can see which ones are listed under the security tag.

Why?

Regular fuzz testing can help us find bugs and potential security issues in parsing . While we hope users aren't going to be regularly scanning malicious renv.lock files we'd still like to be able to handle things correctly if a file is really malformed.

How should I do this?

1. Set up your own environment for fuzzing cve-bin-tool using Atheris. We recommend you use a container or vm for this for safety (a misconfigured fuzzer can potentially make a big mess).
2. Be aware that Atheris and its requirements can be a bit finicky to set up and last time we ran a big fuzzing campaign only some versions of Python in some environments actually worked easily. If you find any issues with following the setup docs, or manage to find good workarounds for an environment we haven't mentioned, please file issues or make a PR to add them to our docs.
3. Create a new proto file (or files) to generate fuzzed renv.lock files and add them to our proto files directory: https://github.com/intel/cve-bin-tool/tree/main/fuzz/proto_files. It's ok to have tests against files that are completely garbage, but probably the most interesting bugs will come from files that mostly look correct, and the proto setup will help you do that. If you're not sure how any of this works, you may find it useful to read this primer on structure-aware fuzzing
4. Make a python file to call your fuzzer. Here's what the cyclonedx fuzzer looks like, as an example. Yours may be considerably different -- feel free to search for other examples and read the Atheris/libfuzzer/protobuf-mutator docs to help you figure out what you need.

Hacktoberfest

I'm filing this with the intention of it being a bug for hacktoberfest 2023. If you're intending to do it as part of that contest, make sure you follow their rules. I believe we have to accept/merge your PR between Oct 1-31 for it to count, and you'll need to register after September 28 but probably before we merge anything. You may be able to open a draft PR earlier. Do let me know if you need something to count for hacktoberfest.

New Contributor Tips

Since this is marked as a hacktoberfest issue there's a good chance whoever does it will be new to cve-bin-tool, so here's the tips we usually put on new contributor friendly bugs

Short tips for new contributors:

• cve-bin-tool's contributor docs
• If you've contributed to open source but not this project, you might just want our checklist for a great pull request
• cve-bin-tool uses https://www.conventionalcommits.org/ style for commit messages, and we have a test that checks the title of your pull request (PR). A good potential title for this one is in the title of this issue.
• You can make an issue auto close by including a comment "fixes #ISSUENUMBER" in your PR comments where ISSUENUMBER is the actual number of the issue. This "links" the issue to the pull request.

Claiming issues:

• You do not need to have an issue assigned to you before you work on it. To "claim" an issue either make a linked pull request or comment on the issue saying you'll be working on it.
• If someone else has already commented or opened a pull request, assume it is claimed and find another issue to work on.
• If it's been more than 1 week without progress, you can ask in a comment if the claimant is still working on it before claiming it yourself (give them at least 3 days to respond before assuming they have moved on).

[joydeep049]

I have been working on issue #2917 for the past two weeks and it seems like it is going to take a bit more time since there is a bit more to be figured out about the way the DebParser is supposed to work.
I have previously worked on adding Fuzz Testing and was waiting if someone else wanted to try it out.
So can i work on this?

[terriko]

@crazytrain328 sure, I've assigned you to this one. Be warned: it may take a while for anything to get reviewed and merged over the next two weeks if it's not essential for the release or really easy for me to approve. But things will be back to normal in January!

[terriko]

(whoops, hit wrong button)

[inosmeet]

Should be completed by #3664