Google's OSS-Fuzz expands fuzz-reward program

[1] https://sos.dev/

https://bughunters.google.com/about/rules/5604090422493184/g...

> Strangely, these bugs were found by the CI of ClickHouse, and not by any of the hundreds of other products using these libraries.

A lot of software projects that have "OSS Fuzz integration" have very naive or superficial fuzz harnesses that couldn't ever get thorough coverage.

If the code is never executed by the fuzzer, bugs won't be found by fuzzing.

In your case, fuzzing your application code, you likely end up executing code in those dependencies that their own fuzzers miss.

Fuzzers are so good because they find so many bugs relative to programmer effort (lines of code). They’re some of the most efficient testing you can do. If I had to choose between a full test suite and a fuzzer, I’d choose the fuzzer.

I use fuzzers whenever I have a self contained “machine” in my code which should have well defined behaviour. For example, a b-tree. I write little custom fuzzers each time. The fuzzing code randomly mutates the data structure and keeps a list of the expected btree content. Then periodically I verify that the list and the btree agree on what should be contained inside the list. In the project I’m working on at the moment, I have about 6 different fuzzers sprinkled throughout my testing code. (Btree fuzzer, rope fuzzer, file serialisation fuzzer, a few crdt fuzzers, and so on).

Writing fuzzers is quite devastating for the ego. Usually the first time I point a fuzzer at my code, even when my code has a lot of tests, the fuzzer throws an assertion failure instantly. “Iteration 2 … the state doesn’t match what was expected”.

Getting a fuzzer running all night without finding any bugs is a balm for the soul.

The code looks like this, if anyone is curious. Here’s a fuzzer for a rope (fancy string) implementation: https://github.com/josephg/jumprope-rs/blob/master/tests/tes...