Fuzzing the Java core libs

Alan Bateman Alan.Bateman at oracle.com
Thu May 13 11:22:17 UTC 2021


On 13/05/2021 10:37, Fabian Meumertzheim wrote:
> OSS-Fuzz files bugs in a Monorail instance (of 
> https://bugs.chromium.org 
> <https://urldefense.com/v3/__https://bugs.chromium.org__;!!GqivPVa7Brio!LZlbpr2Co7I9YJY0B1yH-dDTXPC75YoPU6MypXPpC9mKFrLjekr8J0aLwY8IjWNb-Q$> 
> fame), which can be used to discuss the issues, but of course doesn't 
> have to be. Authentication to that Monorail instance as well as to 
> oss-fuzz.com 
> <https://urldefense.com/v3/__http://oss-fuzz.com__;!!GqivPVa7Brio!LZlbpr2Co7I9YJY0B1yH-dDTXPC75YoPU6MypXPpC9mKFrLjekr8J0aLwY-UosWYAQ$>, 
> which provides additional information on findings and fuzzer 
> performance, is tied to Google accounts.
>
> All findings (security or not) remain confidential for 90 days (+ a 
> possibility for a grace period) or until OSS-Fuzz determines that the 
> finding no longer reproduces against the source repository (i.e., a 
> fix has been committed).
>
> Does the OpenJDK security workflow rely on commits with purposefully 
> innocuous messages to the main branch for embargoed security issues? 
> If that's the case, we should ensure that the OSS-Fuzz policies don't 
> conflict with the OoenJDK security policies before performing the 
> integration.

The workflow is shown on the Vulnerability Group page [1]. There isn't a 
repo that you can test commits on before the publication date.

-Alan

[1] https://openjdk.java.net/groups/vulnerability/


More information about the core-libs-dev mailing list