On 2021-03-05, Fabian Meumertzheim wrote: > I am one of the maintainers of Jazzer > (https://github.com/CodeIntelligenceTesting/jazzer), a new open-source > fuzzer for JVM projects based on libFuzzer.
> I have set up a few Commons projects for local fuzzing with Jazzer, > which lead to quite a few bug reports in Compress and other projects > (https://issues.apache.org/jira/browse/COMPRESS-569?jql=reporter%20%3D%20Meumertzheim). > While the majority of the bugs found are undeclared exceptions, this > approach also caught an infinite loop on a crafted 0.5KB .tar before > it could make it into a release (see COMPRESS-569). Yes, many thanks for that. > Jazzer is in the process of being integrated into OSS-Fuzz > (https://github.com/google/oss-fuzz) for continuous fuzzing on > Google-provided infrastructure (ClusterFuzz). > If you agree this is a good idea, I could set up Compress for fuzzing > on OSS-Fuzz. Also I'd like to point out issues detected by Maksim Zuev last spring and summer who used a different fuzzing tool. When reading archives or compressed streams, Compress consumes a lot of input and we are obviously not validating it in all cases as good as we should. Much of the code assumes it will only ever encounter valid archives. I believe fuzzing can help us finding places where we trust input too much. commons-codec or commons-imaging likely are in similar places. OTOH I'm not sure I understand the requirements of OSS-Fuzz. I haven't read the docs only looked at the image of the process. Seeing a Sheriffbot tracking deadlines makes the me very uncomfortable. I'm a volunteer and so are most others around here. > All I would need from you is a list of emails to which the automated > bug reports should go. The reports are usually directly actionable as > they include stack traces and minimized reproducers. In general I'd think the notifications list of the Commons project would be a the best fit. Of course the nature of the issues detected could lead to the fuzzer uncovering security critical bugs that we may not want to become public before a release fixing it has become available. Stefan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
