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