whoops, the diff was garbled
Ben Bucksch
>! <p>The Mozilla security bug group will have a private mailing list,
>! security-...@mozilla.org,
>
Good.
>to which everyone in the security bug group will be subscribed. This
>! list will act as a forum for discussing group policy
>! and the addition of new members, as described below. In addition,
>! Mozilla.org will maintain a second well-known address,
>! security-b...@mozilla.org, through which people not
>! on the security group can submit reports of security bugs. Mail
>! sent to this address will go to the security module owner and peers,
>! who will be responsible for posting the information received to a
>! security bug.</p>
>
Everybody on the security bug group should be able to subscribe to the
security bug reports list.
The list should (maybe additionally) have the conventional alias
<secu...@mozilla.org>.
>! <p>A typical warning will mention the application or module
>! affected, the affected versions, and a workaround (e.g. disabling
>! JavaScript).
>
* Description of bug
* Maybe limiting factors
(in case only certain user groups are affected, other groups can
safely ignore it)
>If the group decides to publish a warning, the module owner,
>! a peer, or some other person they may designate will post this
>! message to the
>! <a href="http://www.mozilla.org/projects/security/KnownVulnerabilities.html">
>! Known Vulnerabilities</a> page.
>
The mailing list is still missing. It is not reasonable to ask Mozilla
contributors to reload the page twice a day or so.
Christopher Blizzard
>> to which everyone in the security bug group will be subscribed. This
>> ! list will act as a forum for discussing group policy
>> ! and the addition of new members, as described below. In addition,
>> ! Mozilla.org will maintain a second well-known address,
>> ! security-b...@mozilla.org, through which people not
>> ! on the security group can submit reports of security bugs. Mail
>> ! sent to this address will go to the security module owner and peers,
>> ! who will be responsible for posting the information received to a
>> ! security bug.</p>
>>
> Everybody on the security bug group should be able to subscribe to the
> security bug reports list.
>
> The list should (maybe additionally) have the conventional alias
> <secu...@mozilla.org>.
Yes, please. In fact, I would just say shorten that to
secu...@mozilla.org instead of the overly-obscure
security-b...@mozilla.org and just use secu...@mozilla.org.
> The mailing list is still missing. It is not reasonable to ask Mozilla
> contributors to reload the page twice a day or so.
Wow, twice a day? You have trust issues, dude. :)
Seriously, a .announce style mailing list is a good idea.
--Chris
--
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
Mozilla.org - we're on a mission from God. Still.
------------
Mitchell Stoltz
> Yes, please. In fact, I would just say shorten that to
> secu...@mozilla.org instead of the overly-obscure
> security-b...@mozilla.org and just use secu...@mozilla.org.
"security" means different things to different people. I was thinking
that making the address of the list reflect its purpose rather
specifically will lower the amount of noise on the list.
"security" could be interpreted as security feature development, for
example, or as physical security (secu...@netscape.com is supposed to
be an engineering list, but it gets mail for campus security all the time).
security-b...@mozilla.org is long, but why do you call it
"obscure?" Seems pretty straightforward to me.
If people don't think that calling it security-bug-reports will cut down
on noise, or that brevity is more important, then we'll go with
secu...@mozilla.org.
What about the other list address, security-...@mozilla.org?
> Seriously, a .announce style mailing list is a good idea.
Sounds fine to me, although I think the authoritative list should be a
webpage. We can do a mailing list too.
Ben Buchsch wrote:
> Everybody on the security bug group should be able to subscribe to the
> security bug reports list.
Everything I get from the bug reports address will be posted to a bug
right away, and the security group can view it there. That way we won't
have people filing duplicate bugs from the same problem report.
-Mitch
Gervase Markham
>> secu...@mozilla.org instead of the overly-obscure
>> security-b...@mozilla.org and just use secu...@mozilla.org.
>
> "security" means different things to different people.
I'm surprised no-one has yet mentioned
http://www.wiretrip.net/rfp/policy.html . This is Rain Forest Puppy's
Full Disclosure Policy, which has achieved a reputation in the security
world as a fair summary of how reporters and maintainers should interact.
"...the ORIGINATOR should address the ISSUE to:
security-alert@[MAINTAINER]
secure@[MAINTAINER]
security@[MAINTAINER]
support@[MAINTAINER]
info@[MAINTAINER]
regardless of their existence. Anyone who could be deemed as a
'MAINTAINER' is encouraged to populate at least some of the above email
addresses."
Of the above, I suggest we populate "secu...@mozilla.org", because it's
IMO the most sensible and appropriate of the five.
Gerv
Bradley Baetz
>
>Of the above, I suggest we populate "secu...@mozilla.org", because it's
>IMO the most sensible and appropriate of the five.
>
>Gerv
>
Except that mozilla-...@mozilla.org is a public mailing list...
(BTW, Will the 'private' mailing lists be archived somewhere, password
protected?)
Bradley
Mitchell Stoltz
> Of the above, I suggest we populate "secu...@mozilla.org", because it's
> IMO the most sensible and appropriate of the five.
Am I the only one who thinks secu...@mozilla.org is too ambiguous? How
about securit...@mozilla.org (from the RFP paper) or
securi...@mozilla.org? That way people will know exactly what it's
for. That will cut down on irrelevant messages from the clueless.
For the other alias, the private group mailing list, dveditz suggested
secur...@mozilla.org. That one sounds good to me, it's shorter, but
less ambiguous than some alternatives.
Gerv, why should the vulnerabilities page be at
http://www.mozilla.org/projects/security/known-vulnerabilities/index.html?
I don't understand why this is the better option. Does every new page
added have to be an index.html page? I wanted to post this policy in the
same place as the vulnerabilities page, so does the policy need to go at
/projects/security/security-bug-policy/index.html? I don't like putting
each page in its own directory, if that's what you're suggesting. Please
explain.
Bradley, we could archive the private mailing list somewhere if we feel
it necessary...just one more thing to maintain as far as I'm concerned.
We can talk about that later.
-Mitch
Ben Bucksch
> What about the other list address, security-...@mozilla.org?
OK with me, but I don't care much.
>> Seriously, a .announce style mailing list is a good idea.
>
> Sounds fine to me, although I think the authoritative list should be a
> webpage. We can do a mailing list too.
No, my point is specifically that the mailing list must be authorative.
I want to subscribe to that address and be sure that I get notified
about new bugs (modulo technical problems outside mozilla.org). If
someone posts a bug to the webpage only, and thus causing several
parties not to notice the bug, the poster should have no excuse by
saying that the web page is the only authorative source.
> Ben Buchsch wrote:
> > Everybody on the security bug group should be able to subscribe to the
> > security bug reports list.
>
> Everything I get from the bug reports address will be posted to a bug
> right away, and the security group can view it there.
That's good.
> That way we won't have people filing duplicate bugs from the same
> problem report.
We can avpid that by conventions (e.g. only the module owner files these
bugs or anybody can file it, if it's not there already after some time).
But I would still like to have some garantee that I can see all bugs. I
see no reason why not everybody should be able to subscribe.
Mitchell Stoltz
> We can avpid that by conventions (e.g. only the module owner files these
> bugs or anybody can file it, if it's not there already after some time).
> But I would still like to have some garantee that I can see all bugs. I
> see no reason why not everybody should be able to subscribe.
Everyone on the security group will be able to read security bug reports
in Bugzilla after they are received by Mozilla.org, because as module
owner I will make sure that all security bugs that are submitted to
secu...@mozilla.org will be made into bugs in a timely fashion. And
that's my final word on that issue.
-Mitch