Closed Bug 1493793 Opened 7 years ago Closed 7 years ago

Create Core::JavaScript Fuzzer for bugs found by JS-related fuzzers

Categories

(bugzilla.mozilla.org :: Administration, task)

Product:
bugzilla.mozilla.org
Component:
Administration
Version:
Production
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: emceeaich, Unassigned)

Details

I discussed managing the triage backlog for Core::JavaScript:* with :sdetar this afternoon, and they mentioned that we use [meta] bugs to track bugs found by the fuzzers. This causes a couple of issues: important bugs not reported by the fuzzers get lost in the fuzzer bugs, and the list of dependent bugs does not display priorities, etc. Recommend that we break out fuzzer bugs into their own component, and use the name of the fuzzer that found the bug as a keyword. We can move existing bugs into the new component. Because this would be another component in core, we don't have to map groups or flags. Steven, Al, Sylvestre: does this sound good?
Flags: needinfo?(sledru)
Flags: needinfo?(sdetar)
Flags: needinfo?(abillings)
Makes sense. This would help automatic triage and tooling.
Flags: needinfo?(sledru)
This seems like a bad idea unless you just mean the meta bugs. If you mean moving all the normal JS bugs found by fuzzers out of JS components, this would would obscure the bugs. They are JS bugs like any others and usually fairly important ones. I think they should stay with the other JS bugs.
Flags: needinfo?(abillings)
Steve asked me to comment on this as well: I actually see multiple problems with this and strongly suggest to not go for this kind of separation: 1) Fuzzing bugs are highly important to the project. The proposal sounds like separating these bugs from the rest of the bugs so they don't show up in triage lists, essentially declaring these bugs less important. This has a high potential to both harm fuzzing and product stability/security. 2) A lot of automated tooling, searches, etc. depend on these bugs being within their regular components. This change would break a lot of searches and decrease visibility on fuzzing bugs. 3) We would lose information about where in the JS engine we found how many fuzzing bugs. Also fuzzing bugs are not "special" in any way, they are regular crash/assertion bugs like any other bugs found either by tests or in the wild. I do not fully understand what you mean about priorities not being displayed, or what the problem with fuzzing bugs blocking a meta bug is. Could you further elaborate on that?
decoder, the comment around priorities, etc probably came from me. I have been using the Meta bug for looking what are all the fuzz bugs that are still not addressed. It just hard to look at those bugs as a list. I agree I don't want to separate these bugs from the rest of the bugs as they are important and all the points you made. Is there a way to easily look at all the JS related fuzz bugs so I can better manage that list? (i.e. put more focus on addressing them)
Flags: needinfo?(sdetar)
This sounds like something that should be addressed through a search than a different component. :sdetar, a query that would work, if the meta-bugs are long-lived, to find all the untriaged JavaScript fuzzer bugs would be: https://mzl.la/2Q0IfPk. You can add that to your saved searches, and/or set up a nag. :sylvestre, I think given the prior discussion, setting Steven up with the right query can resolve this.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
(In reply to Emma Humphries, Bugmaster ☕️🎸🧞‍♀️✨ (she/her) [:emceeaich] (UTC-8) needinfo? me from comment #5) > This sounds like something that should be addressed through a search than a > different component. I agree. I discussed this with Steven on IRC and gave him the link to our saved search for Open JS Fuzz Bugs. > :sdetar, a query that would work, if the meta-bugs are long-lived, to find > all the untriaged JavaScript fuzzer bugs would be: https://mzl.la/2Q0IfPk. > You can add that to your saved searches, and/or set up a nag. This query doesn't work properly because it uses AND on the blocking bug criteria. We do have a saved search here that does it correctly: https://bugzilla.mozilla.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Open%20JS%20Fuzz%20Bugs&sharer_id=395101 Note that this search doesn't include the "Javascript: Webassembly" component right now. I am not sure if that is intentional or not.
You need to log in before you can comment on or make changes to this bug.