Group Name Guessing Disclosure Policy

[Marc Schumann]

> care so much. But with 4.0 comes Bug.update, and the ability to add or
> remove groups from bugs using the API! Also, I believe email_in.pl will
> support adding groups in 4.0, so there's another opportunity for typos.

I don't think the API is very prone to typos. We offer nice checkboxes
to users in the HTML GUI, and application developers will, too, if
they want their application accepted.
That said, email_in.pl is another story. I can't see it used widely
enough to warrant disclosing group names, though.

>        * There is actually no central way for being able to tell if somebody
> "can see the name" of a group. There are so many possible ways that a
> group's name could be seen (membership, othercontrol, permissions,
> inheritance, admin interfaces, etc.) that it would be nearly impossible
> to effectively write a single method that would tell us whether or not
> somebody can see a group's name or not.

It's difficult, right. But we have something like that in place, right
now. Otherwise it wouldn't work the way we want it.
I'm not even sure we'd have a complicated $user->can_see_group telling
everything, but a $user->can_see_group_in_product (and possibly a
$user->can_see_group_on_bug, too, if there are role-specific
visibilities) or something along these lines. This isn't too hard.

>        * The Group Controls are really complex. So if we have the same error
> for "this group doesn't exist" and "this group can't validly be added or
> removed from this product", then it will confuse the heck out of
> everyday Bugzilla administrators.

App devs, too. I'd much rather see this behaviour documented, though.
If it really turns out to be a problem, add a debugging method (or a
more detailed error message if the user is a member of the "debuggers"
group or whatever).

I don't think we should disclose group names.

   Marc