Hi, The behavior you are observing has only become the standard somewhat recently [1], which is also why I had decided to point it out before we performed the integration [2].
Let me first confirm the facts: It is correct that OSS-Fuzz will automatically open the Monorail bugs to the public roughly a day after a patch has been verified upstream. The bug includes the crashing input, a truncated stack trace and all discussions that have been submitted on it. The detailed OSS-Fuzz report, including the full stack trace and minimized crashing input becomes semi-public: it can be accessed by anyone who is a primary_contact/auto_cc for *any* project hosted on OSS-Fuzz. The rationale for the new policy is explained briefly in [1]. Based on a conversation I had with an OSS-Fuzz maintainer, I would paraphrase this as follows: An upstream patch, no matter how innocuous the commit message may be, always has the potential to give away the fact that it exists to fix a security issue. This is especially true if a malicious third party has any interest in finding security issues in a particular open-source project. However, the easiest and certainly most cost-effective way to find such issues would not be to monitor and audit upstream patches, but rather to dedicate more CPU time to running the project's own fuzzers than OSS-Fuzz. While running OSS-Fuzz for all projects is certainly costing Google a lot of money, outperforming them on a single project is not expensive. Hence, bugs found by OSS-Fuzz should be assumed to be already known to anybody with a particular interest in breaking a particular library. Since test cases produced by OSS-Fuzz are not complete exploits (they are inputs to libraries, not applications), they aren't going to be useful for "drive-by script kiddies" or the likes. From that point of view, where dedicated third parties already have the opportunity to find bugs before the maintainers, this becomes more about keeping the user base in the know about security issues in the libraries they are using, e.g. via a project like OSV [3] as mentioned in [1]. That said, I fully understand your concerns and think that it might be possible to accommodate both your usual patch release workflow as well as the general OSS-Fuzz policies. For example, it could be reasonable to keep the crashing inputs non-public for an extended period of time (e.g. the 30 days bugs originally remained private for after the fix), while the conceptual information about the bug (i.e., it's Monorail entry on [4]) becomes public immediately. Can you think of a "middle ground" like this that would work for Apache? Given that OSS-Fuzz has very responsive maintainers and is fundamentally open-source, I would suggest to open an issue on the repository where follow-up discussions are accessible to a wider audience. It may be the case that the change made in [1] has not received the publicity it deserves yet and I'm sure the OSS-Fuzz maintainers would welcome your feedback on the new policy. If you prefer it this way, I could also create the issue myself tomorrow. Fabian [1] https://github.com/google/oss-fuzz/issues/5255 [2] https://mail-archives.apache.org/mod_mbox/commons-dev/202104.mbox/%3CCAMD8YMQ3ODf%3DTn8YAjsUkmym2wZ3TogR8uMy%2Bhb82asL6YEQhQ%40mail.gmail.com%3E [3] https://github.com/google/osv [4] https://bugs.chromium.org/p/oss-fuzz/issues/list On Mon, May 3, 2021 at 2:59 PM Stefan Bodewig <bode...@apache.org> wrote: > Hi (Fabian) > > by now we've resolved the first issues detected by ClusterFuzz (and I > forgot to credit it OSS Fuzz in Compress, my bad). What we observed is > that the issues became public automatically once the patch fixing the > issue was merged into master and ClusterFuzz reran the test. In the case > of Compress somewhere around 24 hours after fixing things in master. > > So far none of the issues we resolved would be deemed as a security > issue. But now we wonder, what if something indeed was a security issue > that we do not want to become public knowledge before we have cut a > release? Is there a way to prevent a verified and fixed issue from > becoming public automatically? > > Here at the ASF we vote on releases, and we vote on the code base in our > default branch (master for most if not all components). Voting takes at > least three days, so the current behavior would mean the issue became > public knowledge a few days before a release fixing it was available. > > Can you shed any light on this? > > Thanks > > Stefan >
