348704 - bmo customization for "anyone set security bit" needs to be updated

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: General, defect)

Description

[Reed Loden [:reed]]

The bmo customization for allowing anybody to set the security bit needs to be updated.

+     [% IF product == "Bugzilla" OR product == "Webtools" %]
+       [% sec_bit = 12 %] [%# Webtools security group %]
+     [% ELSIF product == "Update" %]
+       [% sec_bit = 23 %] [%# Update security group %]
+     [% ELSE %]
+       [% sec_bit = 2 %]   [%# Standard security group %]
+     [% END %] 

"Update" has been renamed to "addons.mozilla.org". Shouldn't the "mozilla.org" product default to "mozorgconfidential" group? Also, what about "Websites" component? It should not use the standard security group. There may be others to change, too.

Comment 1

[timeless]

mozilla.org should not default to mozorgconfidential, then i couldn't see bugs there! :(

Comment 2

[Dave Miller [:justdave]]

Dan: thoughts?

Comment 3

[Daniel Veditz [:dveditz]]

I'm with Reed on the mozilla.org product. If timeless's resulting lack of access is a problem then fix *that*, don't stuff a bunch of bugs in the wrong group for everyone else. He could be the default QA assignee for the BMO components (myk's probably not right anymore) or add him to the group if he really ought to be seeing them. What is mozilla.org confidential for if not mozilla.org stuff?

Websites and Marketing should probably be mozillaorgconfidential also. Or maybe this "Mozillion Confidential" thing I see I'm a member of? what the heck is that one?

What's the Testopia product? maybe that's webtools security.

Comment 4

[timeless]

testopia would be webtools in my book. what would it take to get me added to mozilla.org confidential? :)

Comment 5

[Gervase Markham [:gerv]]

Mozillion was a marketing campaign which never really happened; I don't know how it got a security group of its own. It currently only has one bug in it, a "Welcome to Mozillion" bug. I think we can get rid of it.

mozorgconfidential is currently being used for confidential bugs of a type which timeless (among many other people) should not have access to. Please don't add new members to that group. If we need new security groups for various projects (such as the website) then let's create them.

Gerv

Comment 6

[Dave Miller [:justdave]]

The group mozillionconfidential has been deleted.  I moved its sole bug into Marketing Private for now (not that it really needs to be their either, but I don't know how much they needed to be public ;)  If for some reason it needs to be resurrected, I did save a copy of the membership list before nuking it.

Comment 7

[Dave Miller [:justdave]]

OK, we have two distinct sets of webtools now which are actively maintained by differing sets of folks, and a couple minor divisions in each of those groups.

"Classic Webtools" all the perl-based stuff: Bugzilla, Bonsai, Tinderbox, LXR, Mozbot, Testopia, etc.

"Recently-created* Webtools" all the php-based new stuff in the last couple years:, Spreadfirefox, Addons, AUS, MDC, each of these seems to have a distinct set of people maintaining them.

The latter group may be worthy of a few separate security groups.  Bugzilla is also increasingly heading off in its own direction, with very little overlap in development resources between it and the rest of the classic webtools.  People in the main Mozilla security group are more likely to fix Tinderbox and Bonsai bugs than people in webtools-security these days.  The folks in webtools-security are mostly comprised of Bugzilla hackers.  Overlap between Bugzilla and Testopia makes sense still, because Testopia is an add-on for Bugzilla.

There is already a mozillacomconfidential group, which is currently only used for the Websites product (mozilla.com stuff in particular).  This is kind of confusing with mozillaorgconfidential also being used, and the mozillaorg one is the one all the employees can see, and is used for stuff in the mozilla.org product (but only for company-confidential stuff, not for security bugs).

Any comments from the peanut gallery?  What set of security groups do we want and which products should they map to when people click the "this is a security issue" checkbox?

Comment 8

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

We already have an AMO security bug, which for historical reasons is named "update-security" or some such.

Comment 9

[Gervase Markham [:gerv]]

Here's a suggested plan:

- Split off Bugzilla/Testopia into bugzilla-security

- Merge update-security and webtools-security into web-security, and use it for 
  all other web tools and web site security issues

- Keep the current security group as-is for holes in other Mozilla products

- Keep Marketing Private for marketing (perhaps renaming it, for consistency, to 
  "marketing-private")

- Keep mozillacomconfidential, perhaps renamed as "mozilla-com-private", for 
  Mozilla Corporation stuff (transplanting any stuff misfiled into 
  mozillaorgconfidential)

- Leave mozillaorgconfidential (mozilla-org-private) for now

Are any other groups needed?

In addition, the local hack we use for allocating security bugs to groups should use product IDs, not product names. :-)

Gerv

Comment 10

[Reed Loden [:reed]]

Assigning to me, as per discussion with Gerv.

I still need the final list of security groups.

Comment 11

[Gervase Markham [:gerv]]

Reed: I'm still having a chat with dveditz, who hit a problem with Bugzilla recently which made him concerned about the impact of any changes. I'll post here when that's resolved, then you can make the patch, and when it's ready to go we can do the group changes in b.m.o. itself.

Gerv

Comment 12

[Reed Loden [:reed]]

Now that bug 303183 has been fixed and bmo has been upgraded to have that patch, we can move forward on this.

Comment 13

[Reed Loden [:reed]]

Plan of action, as proposed by gerv, dveditz, and me (includes a change as per bug 399841):

Plan version 0.3b:

- Keep the current "security" group as-is, for holes in Mozilla
   products such as Firefox and Thunderbird. No change in membership.
   [Products: all in Client Software and Components classifications]

- Split off Bugzilla/Testopia into a new "bugzilla-security" group, with
   members being drawn from the existing Bugzilla project security group,
   [e-mail] (13 people).
   [Products: Bugzilla, Testopia]

- "webtools-security" continues to deal with the remaining webtools. No
   change in membership.
   [Product: AUS, Webtools]

- "websites-security" is created to deal with websites, with
   members being drawn from the [e-mail] mailing list.
   [Product: Websites]

- "update-security", renamed to "addons-security", becomes used for
   addons issues (both the servers and the addons themselves). No change
   in membership. security and webtools-security groups are no longer inherited.
   [Product: addons.mozilla.org]

Other renames:

"Marketing Private"      -> "marketing-private"
"mozillacomconfidential" -> "mozilla-com-private"
"mozillaorgconfidential" -> "mozilla-org-private"
(There may be some moving of bugs between these groups to put them in 
the right place.)

Comment 14

[Reed Loden [:reed]]

justdave, what do you think of the plan? Do you have any changes you would like to make? Is it satisfactory to you?

Comment 15

[Mike Connor [:mconnor]]

Ok, so, one thing I'd really like to see is the idea that we have groups for _people_ and groups for _bug access_.  Inheritance is powerful here, and its easier to maintain in general, IMO.  We can get as fine-grained as we need to be, but keep it easy to give groups of people the right amount of access.

Comment 16

[Reed Loden [:reed]]

Attachment: patch - v1 (untested)

WIP patch on adding support for the new groups and aliasing the old group names to the new ones. Untested.

Comment 17

[Reed Loden [:reed]]

This has been done.