java-sdk icon indicating copy to clipboard operation
java-sdk copied to clipboard

Published 20 hours ago • verified publisher icon dapr

Integrate with Google’s OSS Fuzz service

Open mhoad opened this issue 3 years ago • 7 comments

This was only just released but looks as though it could be a good addition to the SDK test suite. https://security.googleblog.com/2021/03/fuzzing-java-in-oss-fuzz.html?m=1

mhoad avatar Mar 11 '21 21:03 mhoad

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

artursouza avatar Mar 11 '21 23:03 artursouza

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 avatar Mar 16 '21 16:03 mhoad

@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 avatar Mar 16 '21 17:03 artursouza

@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?

mhoad avatar Mar 18 '21 07:03 mhoad

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.

artursouza avatar Mar 18 '21 23:03 artursouza

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!

sahansera avatar Nov 10 '21 08:11 sahansera

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 :)

sahansera avatar Dec 03 '21 06:12 sahansera