I am all in for this. I think it would be a great opportunity for the community to contribute.

Looking into this a little bit more it seems like there is a whole process involved with this that I wasn't originally aware of that is outlined here https://google.github.io/oss-fuzz/getting-started/accepting-new-projects/

@mhoad Thanks for looking into this. One day, we will "have a significant user base and/or be critical to the global IT infrastructure".

@artursouza just one more thing. It seems there might be a viable path still. My understanding here is that the fuzzier itself is open source here https://github.com/CodeIntelligenceTesting/jazzer but the managed ongoing testing is it’s own separate thing. Is it an option still if we handle the infrastructure? Is that even a reasonable goal though?

Let me reopen this in the meantime.

Well, is this something we can run on GitHub actions? If you can try that out and it works, we can take a PR in.

Hi @artursouza I'm keen to look into this. Could you kindly assign this task to me please? In the meantime, I'm happy to spend some time investigating different strategies in running Jazzer against the Dapr Java SDK code base and write down my thoughts here before raising a PR first. Thank you!

I have created a sample repo to test out a path that we could potentially use for this using their autofuzz mode using Docker.

Some observations

• I selected the DaprClientBuilder class along with its withObjectSerializer & withStateSerializer methods
• Jazzer requires the fully qualified method reference per each test. Eg: io.dapr.client.DaprClientBuilder::withObjectSerializer
• The keep_going parameter is set to 1. Otherwise, it will take a long time ( >20mins per test) to complete.
• Per each run, Jazzer creates a reproducible .java file. In my GitHub action, during each run, I mount the current working directory and publish these files as an artifact of the workflow once it's completed. A sample run can be found here & here.

Some questions

• Do we want to run this as a separate GitHub action in Dapr SDK's workflows?

  • Pro: We could always run this against the latest build
  • Con: This could potentially increase the build times

• Do we want to run this as a separate GitHub action?

  • Pro: We could run this periodically without affecting the build times
  • Con: Since this will not be as part of a CI run, the target version will not be the latest.

I'm happy to cut a PR depending on whichever path we choose. Hoping to hear more thoughts on this :)