Open fmeum opened 3 years ago
I think that would be nice in principle, but I would like to first see adoption (a few users) of the java_fuzz_test
rule and also a set of concrete users that would adopt py_fuzz_test
if we get to add it here.
When you say adoption, do you mean of local fuzzing or of the OSS-Fuzz support? I don't know of many non-Google Java-based OSS projects using Bazel to begin with, so the OSS-Fuzz support built into java_fuzz_test
is probably more of a mid- to long-term investment.
On the other hand, local fuzzing support for Java (and potentially Python) for any, also closed source Bazel project is already very useful and was my primary motivation for adding the Jazzer integration. It is however more difficult to measure adoption for this use case.
When you say adoption, do you mean of local fuzzing or of the OSS-Fuzz support?
Either - basically any Bazel project defining {java,py}_fuzz_tests
in their codebase.
I don't know of many non-Google Java-based OSS projects using Bazel to begin with, so the OSS-Fuzz support built into
java_fuzz_test
is probably more of a mid- to long-term investment.
I believe it is important for the code to have real users, if only a handful. Otherwise, we essentially pay the engineering cost (added complexity, refactorings, etc.) while the code never runs in "real-life" to reap benefits.
This was the approach when developing the C++ rules, too: Envoy is a very large early customer that was on board when we started developing the project.
On the other hand, local fuzzing support for Java (and potentially Python) for any, also closed source Bazel project is already very useful and was my primary motivation for adding the Jazzer integration. It is however more difficult to measure adoption for this use case.
I agree with this - local fuzzing support has always been a key feature of the project. But ultimately the proof of usefulness stays in actual usage, so this is why I'd like to make sure the rules end up being used (by Google or non-Google projects, for local fuzzing or OSS-Fuzz - any kind of use).
As a first step, I will mention rules_fuzzing
support prominently in the Jazzer docs once java_fuzz_test
has been released. Users have been asking for Bazel rule support, but of course I don't know whether their projects are public.
If there is interest, I could add
py_fuzz_test
backed by Atheris after the release forjava_fuzz_test
is done.As far as I can tell, this would require the following special steps for local Python fuzzing, everything else would be mostly analogous to the integration of Jazzer:
ubsan_standalone_cxx
to arbitrary sanitizer libraries and extract it into a separate repository rule.OSS-Fuzz support for Python then requires a choice between a) adding the CPython installation compiled in
base-builder
also tobase-runner
and b) crafting a packaging rule forpy_binary
backed bypyinstaller
or a similar tool that can bundle a Python target with a Python runtime (--build_python_zip
may do the job).