Group Name Guessing Disclosure Policy

Max Kanat-Alexander mkanat at bugzilla.org
Tue Jul 20 22:27:23 UTC 2010


On 07/20/2010 03:10 PM, Frédéric Buclin wrote:
> Mandatory groups are never displayed in bugs.

	They are displayed in the XML, and they will be displayed in Bug.get.

> About shown and default
> groups, all we want is $product->groups_available, which we already do.

	But I'm talking about a generic case--are you saying that I should
iterate all products in the database and call groups_available on them
just to know if a group name is visible?

>> 	A user can see a group's name if any user with that group's icon has
>> ever commented on any bug they can see. (Or it might be only the group
>> description--I'm not sure, but that's just as bad.)
> 
> That's a bug which should be filed and fixed.

	How, by making the group icons not have a tooltip, thus making them
rather hard to figure out?

> If we use autocompletion for requestees, then we don't need to disclose
> the group used as the grant group.

	It will be in the JSON-RPC call, if we standardize on group names
instead of IDs for the API, which I want to do.

>> 	In customized installations, there are likely to be additional
>> conditions under which group names can be seen.
> 
> Then they would very likely use their own methods, or re-use one of the
> existing ones above, in which case the error message is totally under
> our control.

	How many customized installations have you worked with or read the code
of? I can promise you that they will have no idea they need to do
anything about this.

>> 	So, instead of creating a performance-draining and extremely complex
>> centralized method for determining all of the above, I figured I'd just
>> modify our policy on the subject.
> 
> I still don't see the relationship with the original discussion, which
> is about disclosing the existence of groups.

	Because Wurblzap was saying that a generic $user->can_see_group would
be easy, which it would not be. What I want is excellent code simplicity
and understandable feedback to the user when they make a mistake.
Excellent code simplicity means a single method for determining the
existence or non-existence of a group, just like we have for products.
This is only possible if we change our policy.

	-Max
-- 
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.



More information about the developers mailing list