Group Name Guessing Disclosure Policy

[Marc Schumann]

2010/7/20 Max Kanat-Alexander <mkanat at bugzilla.org>:
> 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.

I think so, too, that email_in.pl will be useful (and used) for
replies. I don't think it'll see enough usage filing sec bugs, though.

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

Silent failures are a good error handling compromise for common usage.
Dev hindrances can be alleviated by your proposed centralized methods
and a way to ease debugging.

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

Yeah, editwhines.cgi is a good example. I'd expect it to be pretty
much $user->can_see_group like -- isn't it? It eludes me how the logic
can be all that difficult...

Group existence and group visibility are two different things and
deserve methods of their own :)

   Marc