Closed
Bug 129366
Opened 23 years ago
Closed 21 years ago
Allow unprivileged users to file bugs into Mozilla security groups
Categories
(bugzilla.mozilla.org :: General, defect, P2)
bugzilla.mozilla.org
General
Tracking
()
RESOLVED
FIXED
People
(Reporter: myk, Assigned: myk)
References
Details
Attachments
(1 file, 4 obsolete files)
3.00 KB,
patch
|
Details | Diff | Splinter Review |
Each security group should have an option that, if enabled, allows unprivileged
users to file bugs into that group. This makes it possible to set up a group
for security-sensitive bugs (i.e. bugs that compromise the security of users of
the product) and allow members of the public to put bugs into it without the bug
being public for any period of time.
Comment 1•22 years ago
|
||
The groups rewrite should allow this generally, but there is a need for this in
the specific situation of security bugs on b.m.o. This patch is a hack,
specific to that installation, to allow anyone to file bugs into our two
security groups, and add a checkbox to the UI for that purpose.
Gerv
Comment 2•22 years ago
|
||
Yuck...
You nbeed to add some warning text that this doesn't mean 'a problem with
security' (ie nss/psm), and what this means. You could link to a .html page
instead, if you prefer.
Comment 3•22 years ago
|
||
Ditto on the wording objections, this will get misinterpreted and misused. The
text should explicitly mention the confidential aspect somehow. The wording
that's curently used for groupset 2 ("Security-sensitive bug") is not entirely
clear, but wouldn't get misused the way "this is a security problem" would.
Especially if there's a link to a help doc like bug_status.html
"Confidential security problem" ?
If you can, please ask some UI or doc people for wording that gets the idea
across without encouraging overuse.
Comment 4•22 years ago
|
||
Agreed. However, I'd rather have bugs miss-marked as security sensitive (as long
as the volume of such bugs is not too large, or course) than having security
sensitive bugs filed in the open just because we don't give users the ability to
mark bugs as security sensitive.
Comment 5•22 years ago
|
||
"[ ] This is a security problem which needs to be kept confidential"?
People won't read the far end of any link; the text has to stand alone.
CCing mpt and lori for further comments.
Gerv
Updated•22 years ago
|
Attachment #93005 -
Flags: needs-work+
Comment 6•22 years ago
|
||
Comment on attachment 93005 [details] [diff] [review]
Patch v.1
On the patch itsself, if I'm in the security group the UI will look wierd, and
I'm not sure what will happen if you have one checked but not the other. I know
that checkboxes don't send the form element in mozilla (as per the spec), but
does someone send a 0 for unchecked boxes?
ie, move the sec_bit stuff before teh <Tr>, and then do an if. We don't have
the bitset in the user hash though, so you'll have to [% IF %] based on the
group name.
Regarding the ui for this, as a side issue we may want to consider what that
should be when this is done generically and properly.
Theres no reason it couldn't be done properly now, except that it will conflict
strongly with joel's stuff - its only dependent on that because of the product
specific bits.
You shgould also have teh groupset for the m.o conf group for mozilla.org bugs.
Comment 7•22 years ago
|
||
Comment on attachment 93005 [details] [diff] [review]
Patch v.1
On the patch itsself, if I'm in the security group the UI will look wierd, and
I'm not sure what will happen if you have one checked but not the other. I know
that checkboxes don't send the form element in mozilla (as per the spec), but
does someone send a 0 for unchecked boxes?
ie, move the sec_bit stuff before teh <Tr>, and then do an if. We don't have
the bitset in the user hash though, so you'll have to [% IF %] based on the
group name.
Regarding the ui for this, as a side issue we may want to consider what that
should be when this is done generically and properly.
Theres no reason it couldn't be done properly now, except that it will conflict
strongly with joel's stuff - its only dependent on that because of the product
specific bits.
You shgould also have teh groupset for the m.o conf group for mozilla.org bugs.
Comment 8•22 years ago
|
||
The new wording is a big improvement, thank you.
Comment 9•22 years ago
|
||
I think Gerv's revised wording is the best it can be, but I also think this
option would be heavily misused no matter how it was worded.
Comment 10•22 years ago
|
||
I think there's enough of a bias toward openness that it won't be "heavily"
misused, and anyone on a bug can open it up when the mistake is discovered just
as mistakes in severity or components are corrected every day.
You could add a link to
http://www.mozilla.org/projects/security/security-bugs-policy.html if it fits.
Comment 11•22 years ago
|
||
Patch v.2 incorporates new wording and a link to the security policy.
Gerv
Attachment #93005 -
Attachment is obsolete: true
Comment 12•22 years ago
|
||
You've still got the duplicate checkbox problem if I'm in the relevent security
group.
Comment 13•22 years ago
|
||
I _swear_ I wrote a comment about that.
Basically, we have two options:
- make the groups UI inconsistent - one group is a checkbox under the text entry
form, and the rest are as normal
- make the groups UI have a duplicate box for those people in either security
group. People can use either of them to mark a bug as security-sensitive.
Neither is nice, but I believe the second is less bad than the first.
I'm pretty certain browsers DTRT - i.e. submit the control if one or more of the
boxes are checked - so that's not a problem.
Gerv
Comment 14•22 years ago
|
||
OK, I can live with that temporarily. However, please morph this bug into a
mozilla.org specific one, and then file a new one to deal with the generic case
(and mark it dependant on the groups rewrite one)
Comment 15•22 years ago
|
||
This bug was intended to be m.o-specific; I've now made that more clear.
Do we really need a new bug for this issue for the groups rewrite? As I
understand it, Joel has this need already on his list.
Gerv
Assignee: myk → gerv
Summary: option to allow unprivileged users to file bugs into a security group → Allow unprivileged users to file bugs into Mozilla security groups
Comment 16•22 years ago
|
||
Now its mozilla specific :)
I don't think this exact thing is on the groups list-of-changes - joel?
Component: Creating/Changing Bugs → Bugzilla: Other moz.org Issues
Product: Bugzilla → mozilla.org
Version: 2.15 → other
Comment 17•22 years ago
|
||
The current groups plan (stage 3) would permit a product to be set up in a
manner that lets unprivileged users enter a bug but then restricts it in a
manner that the user could not have set up. That would do what this bug wants,
I think.
The way this would be done is to set a permissive entry group for a security
product, but then require the restiction on access. The reporter would still
see it as the reporter, but it would be restricted from public view as long as
it remained in the security product.
Comment 18•22 years ago
|
||
joel: Yes, but that wouldn't be optional then... We'd really want a separate bit
on the product_group_map table for 'can_set_even_if_not_member', which would
only be valid if the entry were optional (ie the type was 1 or 2, not 0 or 3,
from the mappnig Isuggested in the bug/on irc)
Assignee | ||
Comment 19•22 years ago
|
||
Comment on attachment 94667 [details] [diff] [review]
Patch v.2
>+ This is a security problem which needs to be kept confidential
Nit: "that" seems more correct than "which" in this sentence.
>+ (<a href="http://www.mozilla.org/projects/security/security-bugs-policy.html">security policy</a>)
Nit: complete sentences should end with periods.
I'm ok with duplicate UI for this field, although I prefer the "inconsistency."
Comment 20•22 years ago
|
||
Myk's nits picked.
Myk - could you apply this to b.m.o?
Gerv
Comment 21•22 years ago
|
||
myk: ping? :-) I can't file a review request, because we aren't in the right
product.
Gerv
Assignee | ||
Comment 22•22 years ago
|
||
As I recall, the last time staff talked about this we decided not to do it.
Comment 23•22 years ago
|
||
<checks> How right you are. OK. Let's WONTFIX this; if the issue ever comes up
again, I'm sure we'll remember this bug.
Gerv
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Comment 24•22 years ago
|
||
Reopening; we are doing this after all.
Gerv
Status: RESOLVED → REOPENED
Priority: -- → P2
Resolution: WONTFIX → ---
Comment 26•22 years ago
|
||
Over to Myk to apply this to b.m.o.
Gerv
Assignee: gerv → myk
Status: REOPENED → NEW
Comment 27•22 years ago
|
||
I believe the spec says it gets sent for each time it's checked.
If you have two checkboxes with the same name, you're going to get
name=value&name=value in your string.
Comment 28•22 years ago
|
||
Is that going to have any effect on the code which reads this value? Will it
still be in %::FORM, or will it now suddenly be in %::MFORM or something?
Gerv
Comment 29•22 years ago
|
||
I think that if we only check for defined (which I _think_ is all post_bug
does), then its ok. Maybe - test it! :)
Comment 30•22 years ago
|
||
I tried checking both boxes, and it still ended up in the correct group. So
we're fine.
Gerv
Comment 31•22 years ago
|
||
myk: you've applied most of my other customisations, but not this one. Any
particular reason?
Although, now we are forcing new filers to use the Helper, maybe we need this
checkbox there as well...
Gerv
Assignee | ||
Comment 32•22 years ago
|
||
Yes, I didn't apply this patch because it's been rotted by the groups rewrite.
You're right, it makes sense to add this to the Bugzilla Helper as well.
Comment 33•22 years ago
|
||
This should do the trick for the new groups system, and both bug entry forms.
Gerv
Attachment #99710 -
Attachment is obsolete: true
Comment 34•22 years ago
|
||
myk: there's no review system in this product. Could you review, please? :-)
Gerv
Assignee | ||
Comment 35•22 years ago
|
||
I'm a little concerned that this patch makes it possible for group shuffling to
change which groups users can file bugs in, but that's a minor issue and one
which is unlikely to occur. r=myk, and applied to b.m.o, but note that recent
changes to post_bug.cgi necessitate refreshing this patch before the next b.m.o
upgrade. Leaving it open for that reason.
Comment 36•22 years ago
|
||
I have a feeling that the new groups architecture makes this patch redundant,
doesn't it? Joel certainly seemed to think so. So it won't need refreshing.
Gerv
Comment 37•21 years ago
|
||
This has been fixed for a while, right?
Assignee | ||
Comment 38•21 years ago
|
||
Yup.
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Component: Bugzilla: Other b.m.o Issues → General
Product: mozilla.org → bugzilla.mozilla.org
You need to log in
before you can comment on or make changes to this bug.
Description
•