Add rnp_op_verify/rnp_op_decrypt fuzzers to the rnp.

[ni4]

Description

Following fuzzers could be added:

• [x] which utilizes rnp_op_verify_create() and then tries to decrypt-and-verify input data.
• [x] which utilizes rnp_op_verify_detached_create() with some stable input data, and then tries to verify detached signature
• [ ] one which just calls rnp_decrypt() on input.
• [ ] which encrypts input/part of it and then attempts to decrypt (see https://github.com/rnpgp/rnp/issues/1261#issuecomment-674136440)
• [ ] which cleartext-signs input and then attempts to verify

[ni4]

@tomrittervg Does these fuzzers make sense? While it would be impossible to mimic encrypted data, they still would be able to build some non-encrypted packet sequence.

Also, does it make sense/possible to try to process fuzzer's input with some external application? Like, sign with GnuPG and then try to verify?

[tomrittervg]

I haven't gotten to it (yet) but yes, we should ensure we are exercising (for example):

• Signature verification of all forms/algorithms
• Decryption routines of all algorithms
• Packet processing of decrypted data

I don't think it makes sense to take fuzzer input, sign it with GPG, and then verify it, because you're treating the fuzzer input as an opaque blob. Really what you would want to do is is something like encrypt the fuzzer input and use the encrypted data as the entirely of a (e.g.) Sym. Encrypted Integrity Protected Data Packet (Tag 18). That would mean you would be fuzzing the parser of that packet.

However; I think almost all the plaintext packets you would want to fuzz are (a) accessible through fuzz_dump and (b) super simple - just a single type byte or similar.

Another thing to do would be to look at fuzzer code coverage and ensure it's hitting all the packets parsers. I'm currently working on an improvement to the oss-fuzz config to include a fuzzing corpus which should increase coverage. If we're not getting coverage of some parsers, we either need to add files to the corpus to hit them through fuzz_dump, or we need to build a new fuzzer that will route our input to that parser.

But fuzz_dump won't cover the decryption/signature verification paths, so those will need new fuzzers.

[tomrittervg]

See also https://github.com/google/oss-fuzz/pull/4322

[ni4]

@tomrittervg Thanks for detailed reply. Encrypting/signing input looks a good idea, updated the fuzzer list. Actually, while parsing of packets is done via dumping fuzzer, we still need to handle well cases on malformed input which is fed to the rnp_op_verify_create()/rnp_op_verify_detached_create() - to make sure that there are no leaks on wrong input/access violations and so on.