Group Name Guessing Disclosure Policy

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


On 07/20/2010 12:12 AM, Marc Schumann wrote:
> That said, email_in.pl is another story. I can't see it used widely
> enough to warrant disclosing group names, though.

	It will be pretty widely used some day, I think, once it supports
reasonable security and basically allows people to reply to bugmail by
email. That's a feature that I expect nearly every Bugzilla installation
to want.

> It's difficult, right. But we have something like that in place, right
> now. Otherwise it wouldn't work the way we want it.

	Well, we don't *really* have something like that in place. What we have
is a bunch of custom code in various places, and most of them fail
silently instead of throwing descriptive errors. It's already caused me
trouble personally, in some places, where I couldn't figure out what was
going wrong because there were silent failures.

> 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.

	Well, we tend to need it in arbitrary locations, like Bugzilla::Search
and editwhines.cgi. This is what brought up the discussion originally,
actually. So we would need a generalized function.

> I don't think we should disclose group names.

	Well, I'm not technically saying that we should disclose group names,
but I get what you're saying.

	I personally think that the functionality trade-off is worth it,
particularly in terms of the code simplicity it will allow us (the
ability to use Bugzilla::Group->check everywhere to determine group
existence is one advantage).

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



More information about the developers mailing list