I was wondering if you would like to integrate continuous fuzzing by way of OSS-Fuzz? Fuzzing is a way to automate test-case generation and can be used to find unexpected exceptions in Python and memory corruption issues in native code. In this PR https://github.com/google/oss-fuzz/pull/8347 I did an initial integration into OSS-Fuzz. The fuzzer uses a fake odbc driver as a way of communicating with pydobc and the goal is to catch memory corruption issues in the native pyodbc code. I think there is room to extend the fuzzing and would be happy to do so down the line.
OSS-Fuzz is a service run by Google for important open source projects. If you would like to integrate, the only thing I need is a 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.
Hi,
I was wondering if you would like to integrate continuous fuzzing by way of OSS-Fuzz? Fuzzing is a way to automate test-case generation and can be used to find unexpected exceptions in Python and memory corruption issues in native code. In this PR https://github.com/google/oss-fuzz/pull/8347 I did an initial integration into OSS-Fuzz. The fuzzer uses a fake odbc driver as a way of communicating with pydobc and the goal is to catch memory corruption issues in the native pyodbc code. I think there is room to extend the fuzzing and would be happy to do so down the line.
OSS-Fuzz is a service run by Google for important open source projects. If you would like to integrate, the only thing I need is a 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.