Group Name Guessing Disclosure Policy

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Group Name Guessing Disclosure Policy

Max Kanat-Alexander
        Hey folks. So, right now we have a policy that goes like this:

        Group names are confidential. If somebody tries to guess a group name,
we don't want to tell them whether or not that group name exists,
because my guessing infinitely, they could discover confidential group
names. So, if somebody tries to add or remove a group to a bug that
doesn't exist, we fail silently.

        This is OK when the only interface for adding groups is the web UI,
because you can't typo a group name or id--they're checkboxes! :-) So
anybody mis-adding or removing a group is hacking the URL, and we don't
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.

        Bug security is really important--far more important than protecting
against guessing group names. Right now, according to our policy, if
somebody typos a group name (or specifies a group name that can't be
validly added to the bug), it will silently fail. This means that people
will have bugs that they intended to be secure that are actually public,
which is very bad.

        Now, a simple solution sounds like, "Oh, so we should just tell people
that 'the group you specified either does not exist or you cannot see
its name'." However, there are two problems with that:

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

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

        So, I propose that we start explicitly telling people if a group
doesn't exist, and then we explicitly tell them if they are trying to do
something invalid with a group that *does* exist. This means that group
names would be exposed if somebody managed to guess one, but I think
that that is an acceptable fact, particularly if we relnote it for the
upcoming 4.0 release, highlighted as a security change.

        Does this sound OK?

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Mikhail Gusarov-3

Twas brillig at 14:38:24 19.07.2010 UTC-07 when [hidden email] did
gyre and gimble:

 MK> This is OK when the only interface for adding groups is the web UI,
 MK> because you can't typo a group name or id--they're checkboxes! :-)
 MK> So anybody mis-adding or removing a group is hacking the URL, and
 MK> we don't care so much. But with 4.0 comes Bug.update, and the
 MK> ability to add or remove groups from bugs using the API! Also, I
 MK> believe email_in.pl will support adding groups in 4.0, so there's
 MK> another opportunity for typos.

I don't see why URL hacking is different from API hacking from the
security standpoint.

--
  http://fossarchy.blogspot.com/

attachment0 (851 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

David Lawrence-3
In reply to this post by Max Kanat-Alexander
Sounds fine to me.

On 7/19/10 5:38 PM, Max Kanat-Alexander wrote:

> Hey folks. So, right now we have a policy that goes like this:
>
> Group names are confidential. If somebody tries to guess a group name,
> we don't want to tell them whether or not that group name exists,
> because my guessing infinitely, they could discover confidential group
> names. So, if somebody tries to add or remove a group to a bug that
> doesn't exist, we fail silently.
>
> This is OK when the only interface for adding groups is the web UI,
> because you can't typo a group name or id--they're checkboxes! :-) So
> anybody mis-adding or removing a group is hacking the URL, and we don't
> 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.
>
> Bug security is really important--far more important than protecting
> against guessing group names. Right now, according to our policy, if
> somebody typos a group name (or specifies a group name that can't be
> validly added to the bug), it will silently fail. This means that people
> will have bugs that they intended to be secure that are actually public,
> which is very bad.
>
> Now, a simple solution sounds like, "Oh, so we should just tell people
> that 'the group you specified either does not exist or you cannot see
> its name'." However, there are two problems with that:
>
> * 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.
>
> * 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.
>
> So, I propose that we start explicitly telling people if a group
> doesn't exist, and then we explicitly tell them if they are trying to do
> something invalid with a group that *does* exist. This means that group
> names would be exposed if somebody managed to guess one, but I think
> that that is an acceptable fact, particularly if we relnote it for the
> upcoming 4.0 release, highlighted as a security change.
>
> Does this sound OK?
>
> -Max

--
David Lawrence, RHCE  [hidden email]
------------------------------------
Red Hat, Inc.    Web: www.redhat.com
1801 Varsity Drive Raleigh, NC 27606

What happens when open source way is applied to the world? http://opensource.com
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Max Kanat-Alexander
In reply to this post by Mikhail Gusarov-3
On 07/19/2010 02:48 PM, Mikhail Gusarov wrote:
> I don't see why URL hacking is different from API hacking from the
> security standpoint.

        Well, mostly because the URL isn't really an official API, and we don't
expect people to be URL hacking all that often. It's not different from
a *security* standpoint, but it is different from the standpoint of
things we actually expect people to do.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Frédéric Buclin
In reply to this post by Max Kanat-Alexander
Le 19. 07. 10 23:38, Max Kanat-Alexander a écrit :
> Now, a simple solution sounds like, "Oh, so we should just tell people
> that 'the group you specified either does not exist or you cannot see
> its name'." However, there are two problems with that:
>
> * There is actually no central way for being able to tell if somebody
> "can see the name" of a group.


IMO, that's not a big deal. If you are editing groups from
editgroups.cgi, then you are in the creategroups group and the error
message should say "Group Foo doesn't exist", because you are allowed to
view all groups. Else if you are not in admin pages, and you don't
belong to the creategroups group, then the error message should say
"Either the group Foo doesn't exist, or this group is not visible to
you", because you really don't need to know more. All you have to do is
to add

[% IF user.in_group('creategroups') %]
  .. be explicit ..
[% ELSE %]
  .. be vague ..
[% END %]

in the appropriate error message in user-error.html.tmpl.

Remember that turning on the makeproductgroups parameter creates one
group per product. Letting users guess group names means letting them
guess product names as well, which we don't want.

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Max Kanat-Alexander
On 07/19/2010 03:58 PM, Frédéric Buclin wrote:
>> * There is actually no central way for being able to tell if somebody
>> "can see the name" of a group.
>
> IMO, that's not a big deal.

        But it is when you're writing an arbitrary method, from a software
design perspective. We shouldn't be writing a new function for every
single place in the UI that can display the name of a group!

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Frédéric Buclin
Le 20. 07. 10 01:01, Max Kanat-Alexander a écrit :
> But it is when you're writing an arbitrary method, from a software
> design perspective. We shouldn't be writing a new function for every
> single place in the UI that can display the name of a group!

Why would you do that? The same way we don't disclose product names from
a central way ($user->can_see_product()), we can also check the
visibility of a group from a central way, say $user->can_see_group().

LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Max Kanat-Alexander
On 07/19/2010 04:05 PM, Frédéric Buclin wrote:
> we can also check the
> visibility of a group from a central way, say $user->can_see_group().

        No, we can't--that's what I'm saying. The code to do that would be too
complex, and would probably perform badly as well. There are numerous
different situations under which a user is allowed to see a group's name.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Max Kanat-Alexander
In reply to this post by Frédéric Buclin
On 07/19/2010 03:58 PM, Frédéric Buclin wrote:
> Remember that turning on the makeproductgroups parameter creates one
> group per product. Letting users guess group names means letting them
> guess product names as well, which we don't want.

        That's true. Although in the case where group names are confidential,
they can rename the group name to a code name, if they know that group
names can be guessed.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Frédéric Buclin
In reply to this post by Max Kanat-Alexander
Le 20. 07. 10 01:09, Max Kanat-Alexander a écrit :
> No, we can't--that's what I'm saying. The code to do that would be too
> complex, and would probably perform badly as well. There are numerous
> different situations under which a user is allowed to see a group's name.

This is too vague to be helpful. Give me a few examples of these
"numerous different situations" you are thinking about.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Gervase Markham
In reply to this post by Max Kanat-Alexander
On 19/07/10 14:38, Max Kanat-Alexander wrote:
> This is OK when the only interface for adding groups is the web UI,
> because you can't typo a group name or id--they're checkboxes! :-) So
> anybody mis-adding or removing a group is hacking the URL, and we don't
> 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.

If the API were to support group IDs rather than group names, would this
problem be mitigated?

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Max Kanat-Alexander
On 07/19/2010 05:21 PM, Gervase Markham wrote:
> If the API were to support group IDs rather than group names, would this
> problem be mitigated?

        Well, I actually want the API to support group names instead of IDs. I
originally told you to use IDs because of the problem we're discussing
in this thread, but when actually implementing Bug.update and thinking
about how people would use it, I changed my mind.

        Part of the reason to use names is that I want API calls to be portable
across Bugzillas with identically-named groups. Also, names are easy to
understand and see, and group IDs are meaningless. The error "You tried
to add the group 1 to this bug but it is not legal here" is really
unhelpful, as an example.

        Also, the API doubles as the interface for email_in.pl (because of how
Bugzilla::Bug works), and I don't think we want to require inbound email
senders to know group ids.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Marc Schumann
In reply to this post by Max Kanat-Alexander
> 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Max Kanat-Alexander
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.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Marc Schumann
2010/7/20 Max Kanat-Alexander <[hidden email]>:
> 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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Max Kanat-Alexander
On 07/20/2010 12:48 PM, Marc Schumann wrote:
> 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...

        The conditions under which a user can see a group name are ill-defined
and very complex. The conditions I can think of off the top of my head are:

        A user can see a group's name if they can enter a bug in any product
where that group is mandatory, shown, or default for them.

        A user can see a group's name if any bug that they have access to has
OtherControl for that group, even if they are not in the group.

        A user can see a group's name if they have been CC'ed on or are the
reporter of a bug that is restricted to a group that they normally
cannot see.

        A user can see a group's name if they have editcomponents for any product.

        A user can see a group's name if they are in it directly, by
inheritance, or by regex.

        A user can see a group's name if they have global editcomponents,
editusers, creategroups, or are in the admin group.

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

        In the future, these conditions will expand and likely become more
complex. For example, depending on how we do flag requestee
autocomplete, it's possible that users will be able to see the name of
any group that is in the grantgroup of any flag on any bug they can see.

        In customized installations, there are likely to be additional
conditions under which group names can be seen. Customizers (and future
Bugzilla developers) are unlikely to remember or understand these extra
conditions.

        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.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Frédéric Buclin
Le 20. 07. 10 22:44, Max Kanat-Alexander a écrit :
> The conditions under which a user can see a group name are ill-defined
> and very complex. The conditions I can think of off the top of my head are:

It is not very complex...
>
> A user can see a group's name if they can enter a bug in any product
> where that group is mandatory, shown, or default for them.

Mandatory groups are never displayed in bugs. About shown and default
groups, all we want is $product->groups_available, which we already do.
Here, group visibility doesn't matter and we display these group names
in all cases. So this case doesn't need to be considered.


> A user can see a group's name if any bug that they have access to has
> OtherControl for that group, even if they are not in the group.

We use $product->groups_available, as above. Also doesn't need to be
considered.


> A user can see a group's name if they have been CC'ed on or are the
> reporter of a bug that is restricted to a group that they normally
> cannot see.

We use $product->groups_available, as above. Same conclusion.


> A user can see a group's name if they have editcomponents for any product.

All groups marked "Use For Bugs" are indeed visible to them, thanks to
$product->group_controls. Doesn't need to be considered. If the
poweruser tries to hack the URL, then we can tell him that either the
group Foo doesn't exist, or is not a bug group. No need to check his
relationship with the group.


> A user can see a group's name if they are in it directly, by
> inheritance, or by regex.

We use $user->groups directly. Doesn't need to be considered.


> A user can see a group's name if they have global editcomponents,
> editusers, creategroups, or are in the admin group.

It depends which admin page you are talking about, but it's either one
of the method mentioned above, or simply Bugzilla::Group->get_all(),
which do not need to be considered as these methods are all unrelated to
your relationships with groups.


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


> In the future, these conditions will expand and likely become more
> complex. For example, depending on how we do flag requestee
> autocomplete, it's possible that users will be able to see the name of
> any group that is in the grantgroup of any flag on any bug they can see.

If we use autocompletion for requestees, then we don't need to disclose
the group used as the grant group. If the user ignores autocompletion,
then it's enough to tell him that the user he chooses has not the right
privileges to grant the flag. Telling him that the user must be in the
group Foo would be of no help. I know that's what the current error
message says, but it can be reworded once autocompletion works for
requestees.


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


> 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. You need all the methods
describe above, and all are pretty independent. Basically, you don't
want to use Bug::Group->check() in non-admin pages, and admin pages
already have their own methods and error messages can be worded
accurately enough to not confuse the user, without disclosing the
(in)existence of groups when that's not required.


LpSolit
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Max Kanat-Alexander
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.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Gervase Markham
In reply to this post by Marc Schumann
On 20/07/10 13:44, Max Kanat-Alexander wrote:
> 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'm normally the last one to suggest this, but: could we have an admin
pref "Group names are secret"? Have it on, and you have to deal with
vague error messages and the possibility that a typo will accidentally
reveal a bug. Have it off, and, well, your group names aren't secret.

Gerv

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
Reply | Threaded
Open this post in threaded view
|

Re: Group Name Guessing Disclosure Policy

Max Kanat-Alexander
On 07/20/2010 05:17 PM, Gervase Markham wrote:
> I'm normally the last one to suggest this, but: could we have an admin
> pref "Group names are secret"? Have it on, and you have to deal with
> vague error messages and the possibility that a typo will accidentally
> reveal a bug. Have it off, and, well, your group names aren't secret.

        We could, but that would add even *more* code complexity. Then we'd
have to implement alternate code for both cases in every single place
that we check the existence of a group in Bugzilla.

        -Max
--
http://www.everythingsolved.com/
Competent, Friendly Bugzilla and Perl Services. Everything Else, too.
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists@...>
12