Label or comment string to request OSS-Fuzz team look at an issue

[davidben]

OSS-Fuzz bug reports say:

This bug tracker is not being monitored by OSS-Fuzz team. If you have any questions, please create an issue at https://github.com/google/oss-fuzz/issues/new.

However, sometimes reports are caused by OSS-Fuzz infrastructure, not the fuzzers. Recently there have been a slew of build issues. Other times, LLVM regressions have triggered false positives in sanitizers. It is tedious to go to a separate system to report an issue, paste links back and forth, and then manually synchronize the two threads. Additionally, since the GitHub tracker is public, posting becomes extra difficult if it's unclear whether something is sanitizer false positive, or true regression.

I noticed myself even ignoring likely infra issues. The process for summoning the OSS-Fuzz team is difficult, infra issues will likely get reported elsewhere, and I may be too busy at the time for a time-consuming report. But that means rare infra issues go unnoticed. Worse, if it was a true positive, it gets lost in the noise.

There should be an easy, inline way for project maintainers to tag an issue as needing OSS-Fuzz team feedback as part of triage.

[maflcko]

I'd say clang/llvm/libc++ bugs need to be reported upstream, not here.

Though, maybe it could make sense to only bump clang to major versions that are released? There is a new clang release about every 6 months (?), so waiting on new features isn't a lengthy process anymore. The upside would be that all breaking changes hopefully only happen twice a year during a bump and not any time during the year.

[davidben]

Certainly they need to be reported upstream, but as OSS-Fuzz manages the LLVM versions here, they're the next hop. As part of managing that bug, they'll need to temporarily rollback the LLVM update, etc.

[maflcko]

I'd say by using a stable branch, there won't be any need rolling back commits in llvm.

[davidben]

Changes in a stable branch can cause problems too. There may also be build problems not caused by LLVM updates.

I don't think the frequency of LLVM updates has anything to do with this feature request, so let's move that to a separate ticket. (Though I definitely disagree with using a stable branch and would consider it a regression in my project's fuzzer coverage.)

[jonathanmetzman]

OSS-Fuzz bug reports say:

This bug tracker is not being monitored by OSS-Fuzz team. If you have any questions, please create an issue at https://github.com/google/oss-fuzz/issues/new.

However, sometimes reports are caused by OSS-Fuzz infrastructure, not the fuzzers.

Absolutely.

Recently there have been a slew of build issues.

Very sorry for these, I think they should be fixed in the next build.
See #6978

It is tedious to go to a separate system to report an issue, paste links back and forth, and then manually synchronize the two threads. Additionally, since the GitHub tracker is public, posting becomes extra difficult if it's unclear whether something is sanitizer false positive, or true regression.

I noticed myself even ignoring likely infra issues. The process for summoning the OSS-Fuzz team is difficult, infra issues will likely get reported elsewhere, and I may be too busy at the time for a time-consuming report. But that means rare infra issues go unnoticed. Worse, if it was a true positive, it gets lost in the noise.

There should be an easy, inline way for project maintainers to tag an issue as needing OSS-Fuzz team feedback as part of triage.

I can think of a few ways this can possibly supported:

1. Allow users to CC oss-fuzz maintainers on bugs. We may need to be selective about this since it can mess up ClusterFuzz if labels are removed.
2. Have some kind of script that when a certain trigger word is used will create a github issue.
3. Have some kind of trigger word that we can set a mail filter for.

@oliverchang is 1 really infeasible? I like the idea of users having edit permissions since it lets them mark bugs as duplicate or wontfix and will thus improve the quality of our stats.

[oliverchang]

Unfortunately 1 isn't possible to do in a secure way. Granting users edit permissions is something that can only be done for the entire issue tracker. We can't scope that permission by OSS-fuzz project.

3. sounds the most feasible to me.

[davidben]

The OSV import process has made this a lot more urgent. Some related issues:

• Project owners need some way to mark bugs as false positives #11925
• Request OSS-Fuzz project owner approval before importing OSS-Fuzz reports osv.dev#2176
• Withdrawing OSV reports is too heavyweight osv.dev#2177

Now that there are systems that consume OSS-Fuzz reports, OSS-Fuzz needs tools to manage false positives for running fuzzers to be viable.

[davidben]

@oliverchang Was there a reason this was closed as not planned? While it has been a bit since we last had to do this, it's been a frequent problem with OSS-Fuzz when BoringSSL uses it.

[oliverchang]

Thanks for the ping!

This was part of a bulk close to close out some of our older issues (which we're unlikely to get to any time soon). I was hoping to get responses like yours to get an indication of what people still cared about :)