Closed Bug 303183 Opened 16 years ago Closed 14 years ago
Bugzilla fails to warn when a product change would force the removal of an optional group
Moving a security-sensitive bug from Firefox to Toolkit makes it public. I discovered this with bug 303181. I don't know if there's sometihng wrong with bugizlla.mozilla.org's configuration, but it seems to me that even with an odd configuration, Bugzilla should never make a bug public without at least informing the person changing the bug. Maybe Firefox and Toolkit both have a group called "security" and that's confusing Bugzilla?
Assignee: create-and-change → justdave
Component: Creating/Changing Bugs → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
QA Contact: default-qa → myk
Version: unspecified → other
The Toolkit product was set up so that the security group was not allowed to be used in it. Bugzilla did as it was told. It has no way to tell the security group apart from any other bug group, and often times each product has its own mandatory groups which are automatically set. I just fixed the group controls for Toolbox so it shouldn't happen again. That said, I'm almost positive Bugzilla *is* supposed to warn you when that happens. Examining the source on process_bug.cgi, it appears that the warning only gets triggered if the destination product has any groups which are set to be "Default on" but not mandatory. Bugzilla really should warn if a product change would force an *optional* group to be removed. This is sort of the same problem as bug 276553, but coming from a different direction (trying to change the product rather than trying to directly change groups).
Assignee: justdave → create-and-change
Severity: normal → critical
Component: Bugzilla: Other b.m.o Issues → Creating/Changing Bugs
Product: mozilla.org → Bugzilla
QA Contact: myk → default-qa
Target Milestone: --- → Bugzilla 2.22
Version: other → 2.19.1
16 years ago
Summary: Moving a security-sensitive bug from Firefox product to Toolkit makes it public → Bugzilla fails to warn when a product change would force the removal of an optional group
This shouldn't be too hard to fix IMO.
This isn't exactly a regression, so I wouldn't hold up the release on it. However, I would like to see it fixed at some point, possibly also back on the 2.20 branch.
Severity: critical → major
Flags: blocking2.22? → blocking2.22-
Target Milestone: Bugzilla 2.22 → Bugzilla 2.20
(In reply to comment #1) > Bugzilla really should warn if a product change would force an *optional* > group to be removed. If the person changing the product does not have permission to remove the group then the product change should be blocked, or the group should be preserved even if the new product doesn't officially support it. That last must be possible, someone recently filed a new bug in BMO and checked the security issue checkbox, but filed against a product that apparently didn't support that group. The security group was added successfully, and only after I accidentally removed it and found I couldn't replace it did we realize the product wasn't set up to support the security group.
This bug strikes again, security group lost when morgamic switched bug 338114 from Firefox to Update unintentionally leaving bug unprotected.
Not a security bug -> 2.22
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Whiteboard: [sg:want] → [sg:want][wanted-bmo]
Target Milestone: Bugzilla 2.22 → Bugzilla 3.2
14 years ago
Target Milestone: Bugzilla 3.2 → Bugzilla 2.22
This may not be a security bug in terms of people breaking into a Bugzilla machine, but it's definitely one in terms of people getting to see stuff they shouldn't be able to see. A privacy bug, if you like. Gerv
My patch in bug 347213 will fix this bug, but I'm not a fan of backporting it on 2.22.
Assignee: create-and-change → LpSolit
Depends on: 347213
Whiteboard: [sg:want][wanted-bmo] → [sg:want][wanted-bmo][blocker will fix]
Bug 347213 will fix this issue in 3.2, but I will attach a minimal fix for 3.0. We won't take it for 2.22 though.
Status: NEW → ASSIGNED
Target Milestone: Bugzilla 2.22 → Bugzilla 3.0
I can attach a fix for the 3.0.x branch in the coming days. I think it worths waiting for this fix before releasing 3.0.1 as some developers see this bug as security related.
We've lived with it for long enough that I don't consider it a blocker. Of course, if you *do* come up with a patch in the next few days, it'd certainly be *nice* to have.
Flags: blocking3.0.1? → blocking3.0.1-
(In reply to comment #11) > We've lived with it for long enough that I don't consider it a blocker. Well, the friendly folks at b.m.o do consider it a blocker for some stuff we'd like to do. :)
I really need another pair of eyes on this patch, i.e. with heavy testing to be sure I'm not regressing anything. The behavior of process_bug.cgi in Bugzilla 3.2 is definitely better than that (but is too invasive for a backport, as already said). Note that I don't let users have a better control on group restrictions, but display more accurate messages based on what process_bug.cgi really does.
Remove an unused variable + update a comment.
Comment on attachment 271747 [details] [diff] [review] patch for 3.0, v1.1 Fix following things before checkin and this should be ready to go. Group code is pretty complicated so I'm glad QA will happen before release. :) >Index: template/en/default/bug/process/verify-new-product.html.tmpl >=================================================================== > [%# INTERFACE: Add old_groups to interface docs. >+ <p>The following groups are not legal for the <b>[% cgi.param("product") ... >+ <ul> ... >+ </ul> ... >+ </p> An ul tag can't be inside p so the first ul tag implicitly ends the p tag. This causes validation error for the p end tag ending non-opened p tag. You need to add a p end tag before the ul start tag and a p start tag after the ul end tag. >+ <input type="radio" id="add_yesifinold" name="addtonewgroup" value="yesifinold" checked="checked"> >+ <label for="add_yesifinold">yes, but only if the [% terms.bug %] was in any of Nit: There's an extra space before this "yes, ..." but not before the "yes" and "no" radio button texts. This is nit only because this is an existing problem.
Attachment #271747 - Flags: review?(wicked) → review+
Checking in process_bug.cgi; /cvsroot/mozilla/webtools/bugzilla/process_bug.cgi,v <-- process_bug.cgi new revision: 1.351.2.5; previous revision: 1.351.2.4 done Checking in template/en/default/bug/process/verify-new-product.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/process/verify-new-product.html.tmpl,v <-- verify-new-product.html.tmpl new revision: 184.108.40.206; previous revision: 220.127.116.11 done
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.