Mitchell Stoltz wrote: [citation from draft proposal] > Ben Bucksch wrote: > >> Just that this point says "fixed", while I want to inform in both >> cases - when a bug gets discovered (and I have a workaround) and when >> I have a fix. > > That's what I intended. Sorry for the confusion.
That's very good, thanks for the clarification. But now I am a bit confused for another reason. What you say suggests that *you* wrote that paragraph in the proposal, while Frank said, he wriote the proposal without consulting Netscape. > You can inform *your* users via your mailing Yes, they could subscribe > to your mailing list, but fewer people will think to look there than > Mozilla, and the information they find on your mailing list will not > be sufficient to reproduce the bug. That's two levels of protection. [For the record: Here, I am not proposing to release details about a bug. I just propose to issue a vage warning to a dedicated Mozilla list.] Note that the "fewer people" also includes people working on Mozilla. I think, we have the responsibility to protect them. > Absolutely it will happen. Look at all of the bad PR Microsoft gets > about its security vulnerabilities. Whether you consider PR to be a > valid reason is irrelevant - vendors do, and it will affect their > decision to participate. No, the bad PR of Microsoft comes from crackers exploiting (long-known) holes on a very large scale, not from Microsoft notifying users about the holes. Au contraire, the fact that Microsoft issues bugfixes before the hole has been exploited was very *good* PR for Microsoft in the most recent cases. > Let me revise that. "everyone who needs to be protected from an > exploit will be protected." ok. > Users of Mozilla builds are protected by frequent and regular releases > - if you're using dailies, then the bug will probably be fixed in a > matter of days anyway. I disagree here. We have no garantee at all that bugs are fixed quickly. Which means that there is a considerable time where Mozilla contributors are unnecessarily vulnerable. "Unnecessarily", because they could protect them from the bug, if somebody told them to. > If there were really a bug serious enough to delete a user's hard > drive, we (the various vendor reps and security folks) will discuss > via the security newsgroup what the appropriate response should be. > Bugs of this severity are *rare* and can be handled as they come along. This was just a comparison. Few security bugs will delete the harddrive. But many of them have the risk of private data being exposed to unauthorized people. That's what security bugs are all about, not? Or do you have a much broader definition of security bugs than I do? (Which would concern me for other reasons, i.e. that too many bugs end up confidental.) >> and may publically speak about what happens in the security group >> (but not mention specific exploits or details about a bug itself) > > There's a difference between 'publicly' and 'with your own customers.' In this case, I meant public, e.g. talking on n.p.m.security. OK, I was speaking only half as Beonex representative and half as Mozilla contributor. > I believe this is a real difference. What do you mean by "what happens > in the security group?" If you mean matters of policy, those will be > added to the policy document, which will be publically available. If > you mean discussion about sepcific bugs, that's what you can't discuss > publically. What I am thinking of is that I strongly disagree with the decisions made in the security group and that I want people outside of the group to be aware of it. It is basically about discussing policy, but at mozilla.org, from my experience, most people seem to be pragmatic and won't accept a general description of an abstract problem without me mentioning an actual problem which they can discuss. That's why I might want to say (I'm making this up, of course) "We have that buffer overflow bug in HTML form submittion, but these bad boys from Netscape in the security group refuse to fix it correctly, because they say, it would require them to remove that feature which their marketing dept thinks it needs, and to make matters worse, it seems like they are talking the naive reporter into never disclosing the bug." I would of course try hard not to mention enough details to disclose the bug at the same time. In other words, I want only the details of bugs (which can be used to reproduce the bug) to be confidental, nothing else. > All right then, what do you propose? How would you write the policy? See my reponses (and suggestions) to Frank. I already thought about creating an alternative proposal, but it would only summarize what I already wrote and I first want to hear, if Frank or anybody else has any substantional counter-arguments.
