Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Security disclosure - let's resolve this

1 view
Skip to first unread message

Jonas Sicking

unread,
May 25, 2000, 3:00:00 AM5/25/00
to
I think we should have a "security group". If anyone is interested in
"cracking" mozilla then he/she will probobly think it is worth the effort to
get "can-confirm" access.

/ Jonas Sicking

"Mitch Stoltz" <mst...@netscape.com> wrote in message
news:392C5C00...@netscape.com...
> Hmm, guess I'm not sure either. Do people think we should have a "security
group" or
> should it be "anyone who can confirm bugs?" I think either one would be
fine. Sorry
> for the confusion.
> -Mitch
>
> Mike Shaver wrote:
>
> > Mitchell Stoltz wrote:
> > >
> > > If possible, let's make it so that the reporter and anyone CC'd on the
bug should
> > > be able to see it, regardless of their membership in the security
group. We
> > > should also have an understanding about adding people to the group...I
would
> > > propose that any member of the group can add new members, but should
email the
> > > group and make sure there's no objections. No formal voting or
anything, just a
> > > simple "is this okay with everyone" and then proceed in the absence of
> > > objections. Sound good?
> >
> > Sounds fantastic, but it's not the same as ``anyone who can confirm
> > bugs''. I'm happy with it, myself, just wanted to make sure that it was
> > an intentional difference.
> >
> > So we need:
> > - a security group -- I'll go define that now, with (shaver, mstoltz,
> > mitchell, blizzard, brendan) as the initial membership.
> > - hacks to bugzilla such that:
> > = anyone can mark a bug security-confidential, including during initial
> > report
> > = anyone on the Cc/Assigned/QA-contact/reporter lists can see the bug
> > = anyone in the security group can unmark the bug
> >
> > Any takers on bugzilla hacking for the latter?
> >
> > Mike
> >
> > --
> > 2026060.30 1573923.61
>

Ben Bucksch

unread,
May 25, 2000, 3:00:00 AM5/25/00
to
Sorry for pending my followup for so long. So, I'll just dump my ideas
with some keywords. Maybe this is less emotional than my original
followup.

- I really think, we should completely open all bugs to everybody. See
<http://www.tuxedo.org/~esr/writings/cathedral-bazaar/cathedral-bazaar-4.html,
Claim 8 (quoted on <http://www.mozilla.org/quality/>). Vendors have to
find a way to distribute fixes fast.
- IF you won't open all bugs to everybody, at the very least open them
completely to developers with CVS write access. (I don't know, if this
is a subset to the can-can-commit-bugs group.)
- Please also consider the developers and testers, of which we have
nearly 500.000 now. I'm supposed to eat dogfood, but I won't give up my
security and privacy for Mozilla development. I must at least know about
sec. bugs, so I can adjust my usage.

--
<http://www.bucksch.org>

Ben Bucksch

unread,
May 25, 2000, 3:00:00 AM5/25/00
to
Ben Bucksch wrote:
> - I really think, we should completely open all bugs to everybody.

After talking with some Linux guys, I don't think, that's reasonable.
Let me adjust my proposal:

- Completely open bugs as soon as they are fixed
- If a bug can't be fixed within reasonable time (say, 1 or 2 weeks),
disclose it to everybody

Jesse Ruderman

unread,
May 25, 2000, 3:00:00 AM5/25/00
to
> - If a bug can't be fixed within reasonable time (say, 1 or 2 weeks),
> disclose it to everybody

it would be useful to have a "reason for restriction" field that everyone
can see.

"browser security hole reported 5/25, will open bug and hopefully fix by
6/1"

Jesse Ruderman

unread,
May 25, 2000, 3:00:00 AM5/25/00
to
> - Completely open bugs as soon as they are fixed

does that mean "set groupset=0 on fixed bugs"? "post the bug on the
mozilla.org front page and spam all the users, telling them to upgrade"?
something in between?

by the way, this whole debate is pointless until bugzilla's security is
patched up.

Daniel Veditz

unread,
May 25, 2000, 3:00:00 AM5/25/00
to

Good idea. I would recommend a keyword ("security", "exploit"?) to flag
these and using the "Status Whiteboard" field for the other information.
The whiteboard field already exists for this sort of purpose.

The reason for the keyword is so we can search for these bugs once they've
been marked unprivate. While they're private you can search on the Group ID,
but after they'd just meld into the morass of bugs. We can't rely on the
"Security" **component** because I've seen security bugs marked under the
component in which the bug exists. For example, some of the "unsafe skin"
bugs are assigned to Hyatt and given a XPToolkit (whatever it is) component.

-Dan Veditz

Dan Mosedale

unread,
May 25, 2000, 3:00:00 AM5/25/00
to
"Jesse Ruderman" <dav...@home.com> writes:
>
> by the way, this whole debate is pointless until bugzilla's security is
> patched up.

Ummm, what?

Dan


--

Mitch Stoltz

unread,
May 25, 2000, 3:00:00 AM5/25/00
to
Jonas,
I want to be clear about this. People who are determined to crack mozilla
will succeed whether they can see the bug reports or not. No policy on bug
disclosure will stop a determined attacker, especially not when the Mozilla
source is available to all anyway. We are trying to stop casual troublemakers
from using bug reports to take advantage of security holes. That's all we can
reasonably do. That said, I am in favor of the security group plan. Just not
for the reason you give here.
-Mitch

Jonas Sicking

unread,
May 26, 2000, 3:00:00 AM5/26/00
to
One issue is, how casual should you be able to be. I agree that if someone
is determined enough then there is no way of stoping him/her. But the higer
the security the more people we keep off.

Just out of curiosity, if this is not the reason you want a security group,
what is?

/ Jonas Sicking

"Mitch Stoltz" <mst...@netscape.com> wrote in message

news:392DC8CD...@netscape.com...

0 new messages