I was wondering if you would like to integrate continuous fuzzing by way of OSS-Fuzz? In this PR https://github.com/google/oss-fuzz/pull/8103 I do exactly that, namely created the necessary logic from an OSS-Fuzz perspective.
Essentially, OSS-Fuzz is a free service run by Google that performs continuous fuzzing of important open source projects. The only expectation of integrating into OSS-Fuzz is that bugs will be fixed. This is not a "hard" requirement in that no one enforces this and the main point is if bugs are not fixed then it is a waste of resources to run the fuzzers, which we would like to avoid.
If you would like to integrate, the only thing I need is as list of email(s) that will get access to the data produced by OSS-Fuzz, such as bug reports, coverage reports and more stats. Notice the emails affiliated with the project will be public in the OSS-Fuzz repo, as they will be part of a configuration file.
In the event your unfamiliar with fuzzing, then it's a technique used to automate test case generation. It's been used frequently over the last decade to analyse projects in memory unsafe languages to catch memory corruption issues, but is now moving into supporting memory safe languages (hence this PR). In the Python world, the expected bugs to be found at the moment is uncaught exceptions. I'm happy to answer any questions you may have!
Hi,
I was wondering if you would like to integrate continuous fuzzing by way of OSS-Fuzz? In this PR https://github.com/google/oss-fuzz/pull/8103 I do exactly that, namely created the necessary logic from an OSS-Fuzz perspective.
Essentially, OSS-Fuzz is a free service run by Google that performs continuous fuzzing of important open source projects. The only expectation of integrating into OSS-Fuzz is that bugs will be fixed. This is not a "hard" requirement in that no one enforces this and the main point is if bugs are not fixed then it is a waste of resources to run the fuzzers, which we would like to avoid.
If you would like to integrate, the only thing I need is as list of email(s) that will get access to the data produced by OSS-Fuzz, such as bug reports, coverage reports and more stats. Notice the emails affiliated with the project will be public in the OSS-Fuzz repo, as they will be part of a configuration file.
In the event your unfamiliar with fuzzing, then it's a technique used to automate test case generation. It's been used frequently over the last decade to analyse projects in memory unsafe languages to catch memory corruption issues, but is now moving into supporting memory safe languages (hence this PR). In the Python world, the expected bugs to be found at the moment is uncaught exceptions. I'm happy to answer any questions you may have!