I work on this. Happy to answer questions if people have any.

How does the decision get made at Google to open source something?

I'm always confused about what gets shut down vs open sourced vs paid product.

Hi there! I work in the Google Open Source Programs Office. Echoing what others have said, it's usually just a matter of an engineer or team deciding it's something they want to do. Other times, it's a strategic choice.

We open sourced our open source policies/docs a while back, so if you're so inclined you can dig deeper there. These two links will be of particular interest: https://opensource.google.com/docs/creating/ and https://opensource.google.com/docs/why/

+1

I can speak a little bit about what motivated us.

We saw from OSS-Fuzz (https://github.com/google/oss-fuzz) that this sort of thing could be widely useful and wanted non-open source code to benefit from making fuzzing easier.

Thanks Josh! Love the meta-open sourcing.

I would guess that it has to do with the usefulness of the project outside of Google. This project could be applied to so many other things (as OSS-Fuzz demonstrates), so open-sourcing it makes perfect sense. It isn’t some kind of classified algorithm, either.

Open sourcing is usually pushed from the bottom. People decide they care about open sourcing their project at they push for it.

Any plans to port this from GCE APIs to something more provider agnostic, like k8s? A lot of us would like to fuzz on on-prem equipment.

We would like to support this use case.

For now, you can actually do the fuzzing on prem while communicating with app engine. We do this for our OS X bots since GCE doesn't offer OS X.

The other possibility for completely on-prem use right now is running it using the dev server: https://google.github.io/clusterfuzz/getting-started/local-i...

Hi, good stuff! I am curious to know why it was primarily written in Python (according to GitHub 83.3%)?

Just generally speaking, code that does orchestration and testing in general is often easier under a dynamic scripted language over something that is built and compiled, even if it winds up as a custom DSL. I think Python is one of the better options here for the broader community support, and tooling.

Aside: I tend to reach for node/js often for similar reasons (despite detractors) mostly because I'm more comfortable with it over Python or Ruby, but also because it's already integrated to most of the build/test environments I'm working on anyway.

Python is great for writing glue code, so I'm not particularly surprised by the language choice.

I’m curious why you seem to be surprised? It’s one of the most popular languages (even within Google).

That's one of the main languages at Google. And there are moving towards more Go since a few years.

I am quite ignorant on this subject. I looked briefly through the docs, and still feel a little lost. So before I go too much further, would it be possible to use this for web apps or unity games?

>So before I go too much further, would it be possible to use this for web apps or unity games?

Web apps, almost certainly no.

ClusterFuzz (and fuzzing generally) is most useful for finding bugs in C/C++ code so maybe it could work for unity games? I don't know much about them though.

I thought unity was mostly written in either C# or an EcmaScript flavour?

Unity itself (the engine) is written in C++. Game scripts are written in either C# or UnityScript iirc.

Although the engine is currently written in C++, they are in the process of rewriting parts of it in C#, with help of their HPC# subset and Burst compiler, having some ex-Insomniac Games developers like Mike Acton on the team.

Is this the fuzzing tool that was used to find bugs in Bitcoin? I don't see it in the repository.

I don't think so.

But solidity was recently added to OSS-Fuzz: https://github.com/google/oss-fuzz/tree/master/projects/soli...

Keep up the good work, Johnathan! This is a great feature.

Congrats, Jonathan!

Thanks Tanin!

How does it compare to afl?

It uses AFL.

ClusterFuzz is infrastructure for running fuzzers, so we use it to run AFL, libFuzzer, and other domain specific fuzzers we've written.

Using it to run AFL gives us a lot of nice things over using AFL on someone's desktop (such as crash deduplication, automatic issue filing, fixed testing, regression ranges etc.)