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