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/
