Some time back we had a long discussion on this list/newsgroup about
what policies should be followed with respect to bugs concerning
security vunerabilities in Mozilla. I thought it would be a good idea to
revive that discussion; I personally would like to see mozilla.org adopt
some consistent policies re handling reports of Mozilla security
vulnerabilities, and I'd like any such policies to have public review
and comment prior to being adopted by mozilla.org. This message
represents my personal opinions concerning what such a policy might be.

First, I'd like to limit this discussion to the topic of Mozilla
security vulnerabilities that are reported to mozilla.org and tracked
through Bugzilla and related databases maintained by mozilla.org.

In other words, for purposes of this discussion I don't care what
Netscape or any other Mozilla vendor does with security-related bugs
reported to them and tracked in their own internal bug databases.
Vendors can work with mozilla.org or independently, that's their choice;
neither mozilla.org nor anyone else can (or IMO should) dictate what
policies they adopt. I'm only concerned with those things mozilla.org
can control.

Note also that I'm assuming that mozilla.org will _not_ be maintaining
vendor-confidential information in its own Bugzilla database. Whatever
scheme mozilla.org adopts for handling reports of Mozilla
vulnerabilities should be vendor-neutral and vendor-independent.

Now, on to the more controversial part of this posting:

After participating in the previous discussion and doing some additional
thinking, I personally believe that mozilla.org should adopt a policy of
temporarily limiting full public disclosure of Mozilla security
vulnerabilities reported to it. (BTW, to understand exactly what I mean
by "temporarily limiting", please read this posting all the way through
to the end.) I've previously posted some fairly lengthy comments on why
I believe temporarily limiting disclosure can be justified:

news://news.mozilla.org/38E1074A.311159F5%40collab.net

I won't repeat those arguments here. I'll simply say that I believe that
temporarily limiting disclosure of vulnerabilities (again, as I describe
below) is a reasonable compromise between full disclosure of
vulnerabilities and not disclosing at all. I also believe that I may not
be the only person associated with mozilla.org who feels this way, so if
you strongly disagree with me on this question then I suspect you'll
have to convince not just me but others as well.

So what exactly am I proposing? Rather than present an extremely
detailed proposal I've created a "meta-proposal", that is, a set of
broad guidelines and requirements that I think should be satisfied by
any actual proposal to limit disclosure of vulnerability-related bugs.
I'll leave it to others to fill in the details and propose something
more concrete.

So, without any further ado, here is my "meta-proposal":

1. mozilla.org should establish at least two "official" channels by
which reports of Mozilla security vulnerabilities can be made to
mozilla.org. One of those official channels should be submitting a bug
report (of a special type) to the Bugzilla database maintained by
mozilla.org; an alternative channel should be provided by which people
can report vulnerabilities via email to a well-known email address at
mozilla.org.

2. People reporting vulnerabilities to mozilla.org through the official
channels should be assumed to consent to mozilla.org temporarily
limiting disclosure of information maintained by mozilla.org relating to
the vulnerabilities.

3. For vulnerabilities reported through the official mozilla.org
channels, mozilla.org should (at its discretion) temporarily limit
access to information relating to the vulnerabilities to a select group
of people. This "security group" should be chartered by mozilla.org and
should include among its members Mozilla developers deemed able to
rapidly investigate and resolve security vulnerabilities.

4. In addition to the group previously mentioned, the person reporting a
security vulnerability to mozilla.org should always have access to
information maintained by mozilla.org relating to the investigation and
resolution of that vulnerability.

5. Membership in the "security group" should not be limited solely to
people associated with Netscape or any other Mozilla vendor.

6. There should be some reasonable way for an individual to apply and
be approved for membership in the "security group". This does not imply
that such access must always be granted, but rather that the procedures
for selecting the members of the group should be reasonably fair and
justifiable.

7. There should be full public disclosure of the security vulnerability
(and information relating to it maintained by mozilla.org) after some
reasonable amount of time, whether or not the vulnerability has actually
been resolved by then.

That's it for the meta-proposal. Now for some quick comments on why I
chose these particular requirements:

1. Reporting channels. I figured email and Bugzilla (more specifically,
a special type of Bugzilla bug report) were likely to be the most common
ways for people to report problems which are sensitive in some way.
Sending problem reports to Mozilla newsgroups and public mailing lists
obviously defeats the purpose of this, which is why I didn't mention
these as official channels.

2. Consent not to disclose. I thought about specifically asking people
whether they wanted their reports to be fully disclosed or not. But then
I figured this would be redundant and unnecessary: If people reporting
Mozilla security vulnerabilities to mozilla.org want full (or at least
additional) disclosure, they are of course still free to report the
vulnerabilities through other channels as well -- for example, to
Mozilla mailing lists or newsgroups, to Mozilla vendors, to
organizations such as CERT, to private or public forums dealing with
security vulnerabilities, to the press, and so on.

3. Creation of the "security group". I'm content to let other people
make more detailed proposals about who actually should be in the
"security group". My point is simply that if we're going to limit such
disclosure then there has to be such a group, and as a group it should
be chartered by mozilla.org in its capacity as representative for the
broader Mozilla community, and not by any particular vendor.

4. Access for the bug reporter. I believe that the person reporting a
security vulnerability to mozilla.org has a strong interest in being
able to keep track of what mozilla.org or its delegates are doing about
it. This would also serve as a check on the "security group" as well: If
the person reporting a vulnerability were concerned that the group may
be more interested in covering up the vulnerability than in resolving
it, then they would be able to see for themselves whether in fact that's
happening or not.

5. Composition of the "security group". As I mentioned originally, I am
talking about a Mozilla-wide group dealing with problems reported to
mozilla.org and information maintained by mozilla.org. This is not
intended to be a vendor-controlled group.

6. Adding new members. Again, I'm content to let other people make
detailed proposals about how new members might be added to the "security
group". I will say that I think it's important that this be done in such
a way that the existing members of the group feel that they have an
adequate level of trust in new members; otherwise we run the risk that
some members of the group will bypass the group-wide communications
mechanisms and start taking discussions to a private subset of the
group. This internal splintering of the  group could happen in any
event, but I'd like to see us arrange things so as to minimize the
chance that it does.

7. Forced disclosure. I believe forcing public disclosure after a set
time is necessary to prevent unsolved problems from being "swept under
the rug". I'll leave it to others to suggest what a "reasonable" time
period would be.

If you agree with my premise (that mozilla.org should temporarily limit
full disclosure of vulnerabilities) and with this "meta-proposal",
please feel free to supply more detail on how you believe such a scheme
should be implemented. If you think I should revise the "meta-proposal"
then please make suggestions for revisions.

And of course if you disagree completely with my premise of temporarily
limiting disclosure then you're free to explain why, and to try to
convince me that I'm being wrongheaded. But if you want to do this
please first read my previous posting referenced above, in order to know
how and why I came to my particular beliefs concerning this topic.

Frank
--
Frank Hecker            work: http://www.collab.net/
fr...@collab.net        home: http://www.hecker.org/

Frank, you seem to spend a lot of your time "working" at collab.net
actually writing words of wisdom and posting them in Mozilla newsgroups
:-)

Here are some (hopefully useful) comments/data points. If I don't comment
on something, assume I agree with it :-)

A useful document for discussing things like this is Rain Forest Puppy's
RFPolicy, a document on how vendor/reporter relations for security issues
should ideally be handled. It can be found at
http://www.wiretrip.net/rfp/policy.html .

This should probably be secur...@mozilla.org. That's the default
"well-known" for such things, as far as I am aware. A longer list can be
found in the RFPolicy.

I think it's important that emails received are turned into
restricted-view Bugzilla bugs as soon as possible. It might be sensible,
within the confines of how Bugzilla works at the moment, for the Owner
contact for the Security component (or whatever) be the mail alias for the
entire security group.

A relevant RFE for Bugzilla is:
http://bugzilla.mozilla.org/show_bug.cgi?id=39816

I've asked in there whether there's anyone around to implement it for the
next release.

Is this part necessary? Surely the originator of the security issue can go
public at any time, if they feel that mozilla.org is trying to cover
things up, or whatever.

I would replace this with a suggestion that the relevant Bugzilla bugs be
immediately made public upon public disclosure of the vulnerability. This
also avoids the problem of defining a "reasonable amount of time."

I think there's a case for the group to include an "overseer" who, while
not having detailed Mozilla hacking experience, is a neutral third party
who can make sure nothing dodgy is going on. This is more to calm people's
fears about the hidden process than anything else. I'm not sure who would
be appropriate for such a post; ideally, they wouldn't work for any
company who is doing work on Mozilla.

I also think that the security group should be able to decide to co-opt
other developers with the relevant expertise (2/3 vote, or something) -
this would be done by CCing them on the bug.

Gerv

Actually, for the record, I wrote this last night but postponed posting
it until today. Also, I'm responding to you right now while I'm on lunch
beak :-)

Same here. I'll forgo commenting on issues where I either agree with you
or I don't care exactly how the issue gets resolved.

This is indeed useful; thanks for the reference. I didn't include
details at that level because 1) I felt it was premature; and 2) I don't
care about all the fine details, just the overall principles and the
critical details.

Yes, this is true (as I implied elsewhere in my comments). However, what
if the originator doesn't care if the vulnerability gets disclosed to
others, or if they have their own interest in keeping it secret?

IMO leaving disclosure solely up to the originator and the "security
group" does not address the interests of Mozilla users, developers,
vendors, etc., who are not part of the "security group" and who did not
report the vulnerability, but would nonetheless be potentially affected
by it.

I think your suggestion is a reasonable supplement to my proposal;
however IMO it is not suitable as a replacement for a hard and fast time
limit.

This is a reasonable suggestion. However note that I personally would
not volunteer to do this; I'm supposed to be working, remember :-)

Frank
--
Frank Hecker            work: http://www.collab.net/
fr...@collab.net        home: http://www.hecker.org/

I'll comment more on your proposal later, but I'm generally very much in
agreement.

Depending on the time commitment required, I would be willing to
volunteer for that role.  My company doesn't pay me to do Mozilla work
-- though they sometimes permit me to do a little on their time -- and
has neither financial interest nor any other direct interest in specific
bug resolutions or policies.

Unless it's a _requirement_ that the overseer not have detailed Mozilla
hacking experience, in which case I think I'm out of the running. =)

Mike

--
96017.62 89815.20

Goodness me, did the man I had in mind just walk in the door? Funny how
these things happen...

Gerv

On Tue, 24 Oct 2000 13:36:14 -0400, Frank Hecker <fr...@collab.net>
wrote:

I think what you have in mind is some sort of computer emergency
response team (cert) for mozilla.

Though being myself doing security related work in conjunction with
the mozilla browser (and I am paid for doing some sort of mozilla
work, mike, are you listening ? :-) I am not a big friend of
restricting information on security issues.
Mozilla is (and should be) an open product in any way, even in terms
of security. Keep in mind, there is always a door open where
information can slip through and then you have to justify whether you
have to hide anything. As anyone can have a look into the code it is
fairly easy finding out vulnerabilities as such, much easier than with
an "isolated" product like IE.

Many CERTs have opened up themselves to the public lately by putting
vulnerabilities on their web sites imemdiately instead of havinog a
delay.

My opininion: There is nothing to win by delaying vulnerabilities.

As for the policy, I believe the actual bugzilla architecture should
be working fairly well enough to establish a response chain.
Important is a process which does not lead into dozens of patches
(making the browser become a IE like patchwork) but organizes the
incoming reports, checks for confirmation and severity and discusses
the appropriate changes.

Should not be a too complicated organization so response times are low
but some sort of cross checking the fix between several developers
shoulb be in incorporated.

And yes, not to forget, there are a lot of areas inside mozilla where
security is a big issue, so different teams have to be involved.

This is just an unorganized collection of ideas (mine, btw and not
those of my employer :-)

Oliver

I hadn't really intended to get involved in this because it seemed like a
done deal, apart from implementation details but as I've indicated
elsewhere that I'm basically against secret bugs on mozilla.org I suppose I
should justify that a little because its not a rejection of this proposal
at all.

I don't discount the problems that open disclosure on mozilla.org may bring
up.
    * That it might encourage the recording of security problems within
vendor bug lists not being reflected within mozilla.org.
    * That it might encourage copy cat attacks earlier than otherwise and
whilst those bugs were still being fixed.
    * That it might encourage mozilla biased attacks.
    * That it might dissuade people/vendors from taking up mozilla because
all the dirty linen is washed in public.
I agree that this is a matter of balance and I accept that if I found a
security hole that the last place I'd bring it up was in a public forum or
bug report.  However, if you do have an open bug recording system then it
is open and anything that's opened on it should be handled/triaged in the
same way.  I would expect that actual work on a confirmed bug be made
confidential until fixed, but that the bug itself and as immediate a work
around as is possible would be published on the bug report.

This is no different from vendor based reporting, and I can't see a problem
in mozilla.org behaving as a responsible vendor.  After all there will be
vendors (i.e. me) dependant on knowing as soon as possible any relevant
security hole or is the intent that downstream vendors gain a kind of
associate access?

The important difference, if indeed there is one, is in the method taken to
report to mozilla.org a security bug.  If you want to maximise the security
around these bugs then you need to eliminate as far as possible their
reporting on Bugzilla.  This no doubt would involve the bug reporting
wizard and probably catch the majority of casual reporters but it wouldn't
catch them all.

Once it was on Bugzilla, in order to keep it secret, it would have to be
quickly hidden, not all security holes appear as such to the reporters even
if it is obvious to someone else.  The hiding of information recorded is
more interesting to those intent on harm than the majority of open
reports.  On the other hand reporters could easily mistake relatively
benign behaviour for a severe security hole or breach.

So I'm not against attempting to channel security-hole bugs I just don't
want that mixed up with an argument for keeping bugs secret.

It might seem that everyone 'knows' the kind of bugs that this security
group would be interested in but I doubt it.  For instance, would anyone
classify the recent to-ing and fro-ing on webbugs to needing confidential
handling?  Naturally not, after all that is a class of problem relating to
html content in general and its details are well known and public
domain.  However, a user that had suddenly for themselves discovered an
image that wasn't really an image and, without discovering the general
corpus of information about it, came to report it to mozilla.org they would
naturally classify it as a security bug.

So what now is a very efficient triage process because there are so many
eyes now gets bottlenecked in precisely the area that needs accurate and
speedy triaging.

I think also that the drawbacks to open reporting can be over
emphasised.  Microsoft is a continual target for security attacks, no doubt
a great many aren't made public, but a considerable amount of security
holes are reported to the public as a whole.  The motives for doing so
might include encouraging Microsoft to fix them promptly and warning users
in general.

As you say a reporter can always make it public, if the reporter does make
it public then it is likely to be only part of the story and may not
include a suitable workaround or defence, in fact it would probably worse
than handling it openly (the original bug and comment, not the discussion
on fixing it).

The point that only a very few developers would be able or motivated to fix
security breaches doesn't seem to make a great deal of sense, it certainly
puts security into a Cathedral of its own.  If the development of software
that is secure is improved by being in the Bazaar then surely the whole
process benefits?

I don't disagree with the intent of your proposal, nor the setting up of a
Security Advisory group that was well known enough for experienced and
knowledgeable reports to be made to, i.e that had gone through considerable
triage and reproduction.  I don't think though that the reporting of bugs
in general should be messed around with.  If someone does make a security
breach report, triage it normally and publish as effective defence as
possible in the first instance.

Simon

My comments on your comments are below; note that these comments
represent me "thinking out loud" to some extent, since I wanted to
respond to your points as soon as I could. For some of your points I
need to do more investigation before I can properly respond.

Some time back there was a discussion on the mozilla.org staff list
about the current status of the "Netscape confidential" bit in Bugzilla,
but I can't find the full discussions. In any case, Netscape now has
their own internal instance of Bugzilla for tracking bugs for Netscape 6
(separate from bugs for Mozilla proper), so there is certainly no
compelling reason for maintaining the Netscape confidential stuff in
Bugzilla any longer.

However I'll have to defer to our Bugzilla experts on the question of
how many Netscape confidential bugs remain in the public Bugzilla
database, and how soon they could be removed.

I'll respond in greater detail later after I do some more investigation.

Note that after further thinking about this topic, I think there are
actually three separate groups that might become involved in some way in
the process of investigating and resolving Mozilla security bugs:

1. The first group is a core group of people who would be chosen by
mozilla.org to have primary responsibility for the way in which Mozilla
security-related bug reports are investigated and resolved. These people
would be responsible for evaluating initial reports of vulnerabilities,
coordinating the work of people investigating and attempting to resolve
the vulnerabilities, and writing any public statements issued by
mozilla.org concerning the vulnerability.

This core group is really the group I'm thinking of when I use the term
"security group". However there are people who are not part of the core
security group who would still be involved in some way with activities
relating to Mozilla security bugs, as described below.

2. The second group is a wider group of people who might get involved in
investigating and fixing vulnerabilities; this group could include
module owners and other developers in various areas, and people doing QA
work. Only a subset of these people might be involved in looking at a
particular vulnerability, based on whether the vulnerability involves
their particular area of expertise; for example, for a problem
involving, say, buffer overruns in the networking code, the core
security group probably wouldn't need to involve the module owners for
the layout or JavaScript code.

As has been pointed out by others, this second group could be created on
an ad hoc basis for each vulnerability; for example, particular module
owners or other people could be put on the cc list for particular bugs,
with a corresponding Bugzilla feature that limited viewing of a
"confidential" bug to people already on the cc list (in addition to the
reporter and assignee, of course).

3. Finally, there is a third group of people who might not necessarily
be involved in resolving the vulnerability, but who should be kept
informed about it from the moment it is reported and marked as
security-relevant. This group is composed of those who are responsible
for Mozilla distributions and other Mozilla-based products this group
needs to be involved because they will need to fix the vulnerabilities
in their own products in order to serve their own customers. There would
be one representative from each company or organization creating and
distributing these Mozilla-based products (or maybe two, one primary and
one as a backup).

Not to get too deep into implementation at this point, but this group of
people could be put on an "invitation-only" mailing list, and then the
mailing list address could be added to the cc list of bug reports marked
as security-critical. (Presumably this would also allow members of that
list to view the bug reports as well -- again, I don't want to get too
deep into implementation details of how that might happen.)

This last group could be chosen by mozilla.org, based on a number of
criteria: whether the Mozilla distribution or Mozilla-based product is
generally available for public use or not, how big of a user base it
has, how known and trusted within the Mozilla community are the people
behind the distribution, and so on.

If mozilla.org does create such a list of such "distribution
representatives" then it will have to make some judgement calls about
who gets to be on the list and who doesn't, and some people almost
certainly will object to the way in which the selection is done. I don't
see any way to avoid that and still (temporarily) limit disclosure in
some way. And in principle this problem is no worse than the problem of
selecting who gets CVS write access and who doesn't.

I think the core security group (the people responsible for coordinating
investigation and resolution) shouldn't be more three to five people at
most; in my opinion the group doesn't need to be any larger than that in
order to be effective. (The core group can always invite more people to
get involved for a particular bug, as described above.)

The second group (people invited by the core group to help with a
particular problem) could be significantly larger, say 10-30 people.

The size of the last group would be determined by the number of Mozilla
distributions and products. Note that IMO the people on this "Mozilla
distributor" list could and should include representatives from
"non-corporate" projects like Galeon and K-Meleon, not just
representatives from "corporate" projects like Netscape 6,

In my last message I didn't mention a specific time period, but after
thinking about it I agree that a one week period is a reasonable time
length. (You could also state the time period in terms of a certain
number of "business days", say 5 business days.) The purpose of this
initial period is to assess the severity of the problem, put in place a
plan to address it, and write up information for public release; it also
gives Mozilla distributors a chance to figure out how they're going to
address the problem for their own customers.

I don't think a one or two day period before automatic disclosure is
long enough to do that in all cases: people might not be immediately
available, the initial characterization of the problem might be
incorrect or incomplete, etc. That's why I think a somewhat longer
period is better.

You have a good point here. I guess the idea is that if the initial
reporter of the new bug explicitly marked "I want full disclosure" then
no one else would be able to "hide" the bug. (Of course, people could
bypass this by opening a new and separate "hidden" bug, but I don't see
any technical way to avoid that, it's really a social issue within the
project, for mozilla.org to deal with.)

I'm not sure exactly what you mean by "start with proposals for
details". You have already proposed some details about the way in which
security bugs might be handled, and I have added some more proposed
details in my comments above. I don't want to write a complete detailed
proposal just yet; I'd like to see more comments from other people
first. (I also need to go back and re-read and respond to comments
people made to my ...

read more »

BTW: Re timing: With "fast" I meant more days than weeks :).

These criteria are inherently troublesome, even questionable.

But I have no better suggestion. I guess, it depends a lot on the
weigthening - e.g. what you consider "large" and how you weigth the
different critera against each other.

It is, because you can submit patches without CVS write access. It is
just less fun, technically inferior and a bit less convient.
In this case, pleople are potentially cutted from information they need
to do their business.

But again: I have no good solution either.

Oh, that's very small, too small IMO. With brendan, shaver, mstoltz and
jar (sorry, if I forgot someone), you'd have your group complete already.

I think, there are more people who are interested in security bugs and
also trustworthy. If they match both criteria, it is IMO a good thing to
add them to the group - they add more reliability, and they can add
their input or contribute fixes to *any* security bug.

Let's say, I'd make it my goal to make Mozilla more secure. I'd not only
hunt for new bugs and fix them, but would like to be able to see and fix
other known security bugs. Maybe I make it my goal to fix the security
bugs I "like" within 2 hours after reporting, assuming I am reachable.
With your proposal, I couldn't.
I don't think, this is an unreasonable or uncommon scenario, i.e. I hope
there will be more than 3 of those people in the long run, not counting
those who /occasonally/ provide fixes or input for random security bugs.

Since many people work on a volunteer basis, I'd make like to make
"invitation" to contribute fixes more the exception than the regular
process.

I imagined it like that: If a bug is found in a particular area, the
person causing the bug, the module owner and a few other relevant
people, assuming trust, are cced. The first person who claims the bug
assignes it to him-/herself. Usually, the person who caused the bug will
be interested in fixing it him-/herself. Or the other "area specialists"
or the frist security group could jump in, whoever is faster. Others
review / provide input.

Sure.

But I think, that group would be easiest to get into, so it would impose
the largest risk.

Note that holidays are different all over the world.

IMO *this* should be a matter of hours.

I think, the period should be enough to fix the problem in most cases.
That's the rationale behind the temporay hiding - being able to fix the
problem before any cracker has a chance to exploit it (ideally) - not?

That's OK, for the reasons you gave in your initial post, not?

(You cannot "unconfirm" a bug either.)

You're heading in the right direction. I just wanted us to get concrete
now, since we seem to have, IIRC, mostly consensus on your
"meta-proposal", and it is about time to implement it.

I've been quiet on this issue lately, but please don't think I haven't
been paying attention. I would really like to see this "security group"
get off the ground; I think it's the right way to go. I will speak to
someone in Mozilla about making the necessary changes to Bugzilla; the
actual rules should be worked out here in the newsgroup, hopefully by
consensus.

Please understand that the only reason I'm still using the
NS-Confidential flag in Bugzilla is that I don't have a good
alternative. The Mozilla security group would be that alternative. We do
have an internal bug database at Netscape, but there's no easy way (that
I know of) to move bugs from the internal database to Bugzilla. This
slows down the process of disclosing these bugs after they are fixed.
I'd much rather be able to simply flip a switch on these bugs at the
appropriate time, which is why I'm still using Bugzilla.

I support disclosure of security bugs to a trusted group of Mozilla
participants. Believe me when I say this is a priority, and that the
security folks at Netscape will participate in this as much as we
possibly can. Remember though, that there are now over two million users
of Netscape 6 who will be harmed by premature disclosure of security
bugs. Our participation in the security group means trusting the safety
of our users to everyone in the group. This is a difficult position for
a company like Netscape. Please just keep that in mind.
      -Mitch

--------------------
Opinions are mine, not Netscape's

Let me tell you of it :-) Bug can be exported and imported as XML both
ways (assuming Netscape IS is running a version of Bugzilla with Dawn's
XML patches.) It's currently used for moving Netscape 6.0-only bugs from
Bugzilla to Bugscape, but there's no reason why it couldn't go the other
way.

However, this may not solve any of your problems...

Really? Wow...

Gerv

If we maintain a special "notification list" for Mozilla distributors
(as I discussed), my proposal would be to let the core security group
approve who is on it -- after all, if there are people put on that list
who the security team does not know and trust, then the security team
will be motivated to communicate less through Bugzilla and more through
private email -- and I believe mozilla.org has an interest in
discouraging their doing that (unless it's absolutely necessary).

Yes, you are correct that there are differences between getting CVS
access and getting on the list for immediate notification of
vulnerabilities. But again, we are talking about people being cut off
from information only for a limited period of time.

OK, I'll modify my proposal: mozilla.org will appoint an initial group
of people to the core security team; if the team wants to add additional
members then it can do so, using whatever methods and criteria they
decide. I don't care if the security team decides if they need 5 people
on the team, or 15, or whatever. What I do care about (from a
mozilla.org point of view) is having only one or two people that are
held responsible for the security team's operation; in other words, I'd
like to see the equivalent of a "module owner" for this task.

With my new proposal you could, if you convince the security team that
you would be a useful person to have on their team.

The "invitation" is to people who already have responsibility for a
particular area, including in particular module owners for that area. In
my opinion if a person is a module owner then they should be responsible
for providing a rapid response to requests for help with security
vulnerabilities. They don't necessarily have to do all the work
themselves, but they have to at least recruit other people who could
help.

This scenario sounds reasonable, except that I'm not sure what you mean
by "the person causing the bug"? Do you mean the developer who is
responsible for the code in which the bug occurs? Or do you mean the
person reporting the bug?

As I discussed above, I think that the core security team (or perhaps
just the team leader or "module owner") should approve people who want
to be added to the distributor list, as the security team will have to
live with any risk.

Ideally, yes. But I myself don't want to guarantee this can always be
done in a few hours, because I myself will not be the person who has to
fulfill it.

Again, I'll let the people who might be on such a security team say
whether such problems can always be resolved in a day or two, or whether
it might take longer in some cases.

Yes.

OK, if you or anyone else has more suggestions please post them.

Frank
--
Frank Hecker            work: http://www.collab.net/
fr...@collab.net        home: http://www.hecker.org/

But this period is important. Distribution of fixes takes 1 or 2 days
*at least*. Within that timeframe, crackers would know about the
vulnerability and users of those "unfortunate" distiributions would be
vulnerable. OTOH, users of "approved" distributions would be secured
already, which is a competetive advantage for the latter distributiors.

Note: I don't suggest to let "everyone" in the group. I'm just showing
the problem.

Yes, that makes sense.

Agreed.

Yes, the person who wrote the code which shows the vulnerability. Often
(but not always) the person who last touched the line, as shown by bonsai.

I think, all members of the team should have a vote on new members, if
appropriate. This avoids the group being controlled by a single person.
The inital members have enough power already, because they are the
"root", i.e. determine the character of the group by selecting the next
members, which again....

Well, I have no experience either, but I think, this should be possible,
and we should madate it, if it is. See my post about the "security
annoucne group".