Closed Bug 128590 Opened 20 years ago Closed 2 years ago
Allow reporters to uncheck security flags
According to the mozilla.org security policy, the reporter may disclose a bug at any time. At least bugzilla.mozilla.org doesn't allow him to, because only those in the group who can view all bugs with that flag have the checkbox enabled. The reporter (if not in the security group) can't. Reproduction: 1. Create a new bugzilla user. 2. File a security bug 3. Let a bugzilla user in the security group check the security flag 4. Log in as the new user again, try to uncheck the flag Actual result: You cannot - checkbox is disabled. Expected result: Reporter can uncheck security flag.
as a note about this, since BenB wanted to silence me, and I don't like being silenced (I wouldn't have posted this if Ben had kept quiet): sometimes it's nice that reporters can't move things out of security... I can just imagine the malicious hacker who reports a sec bug, but before it can be fixed, unhides and announces it... so -1 on fixing this.. imo.
I don't really agree with the policy, so I doubt we should do this as a default in Bugzilla. Perhaps mozilla.org should apply a patch of their own here. Customising this will likely be dealt with for the fine-grained security stuff that's targetted at 2.20 currently.
::sigh:: To the best of my knowledge this was on purpose, however, you're right, it's a violation of mozilla.org's security policy. I can think of plenty of reasons you *wouldn't* want the reporter to be able to uncheck a particular group (the security box is just another group, nothing special about it) such as in commercial installations using 'usebuggroups' where a bug is secured by product and you don't want competing customers to see each others' products, etc. Probably the best way to handle this is a per-group setting of whether to allow non-group members who have been invited to participate in a bug to remove that group flag. This will probably be easier (as Matty noted) after bug 68022 and bug 110947 are in, since our group handling will be much more flexible at that time...
Depends on: 110947
Target Milestone: --- → Bugzilla 2.20
> BenB wanted to silence me I was joking. > I can just imagine the malicious hacker who reports a sec bug Why should he do that? Reporters being able to unhide thier bugs is a central part of the mozilla.org security policy. Disagreement with that should go to n.p.m.security :).
well, whatever the reason, I would not like it to be default behaviour that a reporter could change the security options.. as an aside, maybe the reporter has too much access.. but that's another issue.
As Ben notes, the official policy on handling reports of Mozilla security vulnerabilities states that a person reporting a Mozilla security vulnerability should also have the ability to make public the confidential Bugzilla bug report relating to that vulnerability. So the only question is how to accomplish this. My personal opinion is that allowing the bug reporter to do this through the Bugzilla interface is a good idea. In the absence of such a capability, the reporter would have to request that someone else, e.g., the module owner or a representative of mozilla.org, clear the "confidential" flag. But in any case the current mozilla.org policy should be embodied in some procedure, whether automated or manual. People who disagree with the policy should take it up with mozilla.org staff; IMO it's off-topic for this bug.
I believe this was partially fixed by the product groups rewrite in 2.17.3 (at least the capability within Bugzilla anyway). Although I don't think it's limited to reporters, I think the new security model allows you to set groups in a given product so that anyone who can see the bug can remove the security flag, whether they have access to the security group or not. Although I think this would also allow anyone to set that flag (although once it's set, they've have to be a member or listed on the bug to see it) Joel?
Well, right now a user can only place a new bug in a group of which he is not a member (if permitted) and a non-member can never remove a group restriction from a bug. Naturally, anything is possible, but we really need to give some further thought into the nomenclature if we wanr to add another pile of options.
[this showed up in a search for something else - here goes with a 2p worth!] It stands to reason that if the reporter can *see* the confidential discussion, he is also capable of copy-pasting it anywhere he chooses. This is also commented on in the mozilla security policy. It would seem preferable that if the reporter chooses to publicly disclose the vulnerability, that it is done on the official bug report so that the security team know about it immediately and can put suitable emergency measures into place (e.g. disabling the vulnerable function). A suitable warning next to the box should probably be given together with a link to the relevant part of the mozilla security policy.
This bug has not been touched by its owner in over six months, even though it is targeted to 2.20, for which the freeze is 10 days away. Unsetting the target milestone, on the assumption that nobody is actually working on it or has any plans to soon. If you are the owner, and you plan to work on the bug, please give it a real target milestone. If you are the owner, and you do *not* plan to work on it, please reassign it to firstname.lastname@example.org or a .bugs component owner. If you are *anybody*, and you get this comment, and *you* plan to work on the bug, please reassign it to yourself if you have the ability.
Target Milestone: Bugzilla 2.20 → ---
This looks like specific to b.m.o. My vote to move it to mozilla.org. I see no reason why the reporter should be allowed to go through group checks and make the bug public. At least, I would deny review any patch going in this direction. If the bug should not belong to some given group, let a user from this group remove this flag.
This should be fixed in Bugzilla proper. bmo isn't that special, any open Bugzilla could reach the same decission and forking Bugzilla is not something we should be encouraging. justdave: is there some magical incantation we need to go through to arrange for this to be fixed as part of mozilla.com?
Assignee: myk → justdave
(In reply to comment #9) > It stands to reason that if the reporter can *see* the confidential discussion, > he is also capable of copy-pasting it anywhere he chooses. This is also > commented on in the mozilla security policy. That's what mconnor said on IRC too. But in this case, anyone in the CC list could do the same (copy-pasting). Does it mean they should be allowed to remove the security flag too?? By reading all comments again, I'm happy to see that I'm not alone thinking we shouldn't do it (about the reporter).
I don't see a constructive reason, with the myriad of existing admin UI, why adding per-group support for reporter access to remove a bug from that group is so evil. This would be an off by default option that would be set per-group.
Bug 189627 has gone off in a slightly different direction and doesn't really have much to do with this bug anymore, so removing the dependency. I agree with mconnor, an additional flag on the group control settings in editproducts seems like a good approach for this. If you care enough about it to want it done on Mozilla paid time, you'll need to talk to schrep. I have enough things on my plate right now to keep me busy for a few months yet before this would make it anywhere near the top of my list currently.
Assignee: justdave → create-and-change
No longer depends on: 189627
(In reply to comment #14) > adding per-group support for reporter access to remove a bug from that group is > so evil. This would be an off by default option that would be set per-group. I don't think it worths making the group control map UI more complex to do this. I see users marking bugs as FIXED when a patch is attach all the time, probably thinking that the bug is now fixed because it has a patch (despite it has not been reviewed yet, and so has not been checked in). Such users would do the same mistake with security flags (and other kind of flags) too. My opinion is that users knowing how security works and who should be allowed to remove the sec flag already are in the required group. Other users, including the reporter, should be excluded from this group of "decision makers". The goal is not to prevent the reporter from making the bug public if his goal is to intentionally make it public (we cannot prevent him from copying and pasting the whole discussion of the bug); the goal is to prevent accidental actions because the reporter thought it was fine to remove the sec flag. I'm pretty sure you would cry if a reporter was making a severe security bug public before you had the time to do the whole QA cycle before releasing the next version of your product. In the same way the reporter is not allowed to edit all fields of his own bugs, he is not allowed to edit group restrictions. I strongly and definitely suggest to mark this bug as WONTFIX, despite what your bmo policy says about this topic.
As explained in my previous comment, I don't want to leave reporters remove their own bugs from groups. So this is WONTFIX as an upstream feature/bug. But as b.m.o wants it, and per my discussion with justdave on IRC today, I'm moving this bug in the mozilla.org product, so that you can implement it locally.
Assignee: create-and-change → nobody
Component: Creating/Changing Bugs → Bugzilla: Other b.m.o Issues
Product: Bugzilla → mozilla.org
QA Contact: default-qa → other-bmo-issues
Version: unspecified → other
I was CC'd so I guess someone wants my opinion. I agree with Frédéric for groups in general, so if we do implement this in BMO please restrict it to the minimal amount necessary to comply with our security bug policy: the Reporter (not CCs) should be able to uncheck the core-security bit but not any other groups. Members of the group should continue to be able to edit the group setting at will. I don't feel terribly strongly about the CC's not being able to do it since they could of course repost the information elsewhere. But if they're not members of the group I'd rather have some minor barrier to mistakes or momentary poor judgment.
If the concern is people accidentally making bugs public, we could make a JS warning appear when you uncheck the box. That would be good for members of the security group too, not just reporters.
See also bug 504461, "Allow everyone to make bugs security-sensitive retroactively".
Summary: reporter cannot uncheck Security flag → Allow reporters to uncheck security flags
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
WONTFIXing this has nothing to do with policy, merely reality. We can reopen this if we revisit it.
Priority: -- → P5
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.