On Wed, Mar 4, 2009 at 5:13 PM, James Carlson <james.d.carl...@sun.com> wrote: > That doesn't sound quite right to me. When a real security bug is > filed, the *submitter* must mark it that way, even if the submitter is > not part of the special group. If it doesn't work that way, then > security bugs will "leak," and that will violate agreements we have > with other parties (as well as our own policies). > >> [ ] This is a security problem that should be kept confidential >> until addressed (security policy). > > OK.
Yes, this is the thing to address your previous requirement > That's what we need, but it can't be something that only a select few > can set. Right, it isn't, it's available in bmo as a customization (which magically maps to a product specific security group), and would be implemented for opensolaris in a similar manner. > More generally, it'd be nice to have a "private to group X" flag. > That would allow Intel (or any other contributor) to file their own > sensitive bugs, and manage them as they see fit. that's what the section below is: >> [ ] Security-Sensitive Core Bug > I'm not sure I understand that one. Either a bug is being cloaked > because it's security sensitive or it's not. > Why would there be two flags? The first flag is the generic one. The second one is the real underlying flag, I see it because i'm in the group. You could have dozens of them in the list. If I were in the intel group, I could see: [ ] Intel Bug I probably should have used a different example. https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org Only users in all of the selected groups can view this bug: (Leave all boxes unchecked to make this a public bug.) [ ] Security-Sensitive Core Bug [ ] Security-Sensitive Webtools Bug "Security-Sensitive Core' and 'Security-Sensitive Webtools' are distinct (possibly overlapping) groups of people. We could have one named 'Intel', but since it's private, I couldn't tell you about it :). For me, if I'm lazy and I file a bug in mozilla.org, I can check [ ] This is a security problem that should be kept confidential until addressed (security policy). And bugzilla will automatically assign it to *a* group, however, I don't remember which of the two groups it'll pick (Core or Webtools). As I'm a member of both, if I'm filing a security bug in mozilla.org, then I probably know to which group the security bug should be assigned, and should therefore "micromanage" the assignment by selecting the appropriate group. (Core=Gecko fwiw, Bugzilla is an example of a Webtool, however it now has its own group...) My employer's Bugzilla has dozens of companies listed as groups, so I could mark a bug into one of those, however as it's private, I won't name them :). One thing about groups... viewing a bug is an <and> relation on all group restrictions. If I create: group "Intel" group "Sun" product "Solaris-x86" Shown/Shown Intel; Shown/Shown Sun and an admin marks a bug as [x] Intel Bug [x] Sun Bug, then generally* unless you are a member of both the "Intel" group and the "Sun" group, you won't be able to see the bug. For my example w/ mozilla.org, if I checked both 'Core(gecko)' and 'Webtools', then I could see the bug, but most people who work on Gecko security bugs couldn't (because they aren't members of Webtools) and most people who work on Webtools security bugs couldn't (because they aren't members of Core Security). * an exception is available once the bug is filed of this form (which is visible in the bug once a bug has a non mandatory group applied): Enable Role Visibility: Users in the roles selected below can always view this bug: (The assignee and QA contact can always see a bug, and this section does not take effect unless the bug is restricted to at least one group.) [ ] Reporter [ ] CC List This enables someone (e.g. an admin in my example) to CC someone who works for Sun (but not Intel) or Intel (but not Sun) to the bug and have that person be able to see the bug even though the person probably doesn't work for both Sun and Intel :). It is possible to make collaboration groups, but the typical group set you would try to make (Sun = *.sun.com; Intel = *.intel.com) will not result in something that works. You're more likely to need SolarisX86 = *.(sun|intel).com). -- These are all examples and the syntax is actually not precisely as I've written it here (it's a regexp, so you need to escape the .'s ...). _______________________________________________ tools-discuss mailing list tools-discuss@opensolaris.org
