search

google / oss-fuzz

OSS-Fuzz - continuous fuzzing for open source software.
https://google.github.io/oss-fuzz
Apache License 2.0
10.16k stars 2.17k forks source link

Reduce disclosure policy window from 30 days after fix. #5255

Closed oliverchang closed 3 years ago

oliverchang commented 3 years ago

With the release of OSV, we've created a better way for users of open source (and OSS-Fuzz projects) to be aware of vulnerabilities affecting their version of a library.

Unfortunately, the current 30 day disclosure window after a patch is released means that affected users of a vulnerable library do not get notified for up to 30 days. We are planning to reduce this to immediately after the fix is upstreamed. The existence of a patch in the upstream repo already discloses the vulnerability, so this is minimal additional risk in return for a large benefit (more timely notifications).

The new deadline text will read (the "30 days" part is removed):

After notifying project authors, we will open reported issues to the public in 90 days, or after the fix is released (whichever comes earlier).

bodewig commented 3 years ago

While we discussed OSS Fuzz publication policy in the context of the Apache Commons Compress library I've been pointed to this issue here. I'd like to share a few observations with you. I'm just talking for myself and not for the project - and much less for the Apache Software Foundation as a whole.

There has been some misunderstanding about the wording of "a patch is released" that is used in OSS Fuzz documentation as well as this issue. "Released" obviously means different things to different people. For OSS Fuzz released means "hits the default git branch", for an Apache project it means "we've created distribution artifacts from the default branch, voted on them for three days and published them". Some of us have been quite surprised when the issues became public knowledge more pretty soon after fixing them. That's not what we had expected from just reading the docs.

Furthermore the current policy is incompatible with Apache's policy for handling security issues - in particular point 14 in https://www.apache.org/security/committers.html . I'm not here to discuss or argue which policy is "right", if there is a "right" at all. Just want to point out they contradict each other.

Finally there are some downstream consumers of OSS Fuzz' issues that seem to flag (some?) issues found by OSS Fuzz as security critical when neither OSS Fuzz itself nor the project does so. JFrog's Xray(?) tool is reported to consider https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=33500 a security issue, for example - something the project doesn't consider a critical at all. This is could obviously happen for each issue detected and disclosed.

To be honest I'm not sure what to make out of this. To me it looks as if this policy was a bad fit for projects with lengthy release processes - as well as for projects driven by few volunteers with limited spare time.