Ben Bucksch wrote:
> Mitchell Stoltz wrote:
>
>> You've both missed this point:
>> --- begin quote ---
>> Mozilla distributors participating in security bug group activities
>> can mention in their release notes that a security bug has been fixed,
>> but we ask that they be vague and not describe the exploit in detail.
>> --- end quote ---
>
>
> No, I didn't. 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. You can inform *your*
users via your mailing list, release notes, etc, as long as you make an
effort not to provide enough information to allow someone to reproduce
the bug. If for a particular bug you feel this is impossible, or you're
not sure how much to divulge, it was our intent that you send mail to
the security group mailing list and we'll discuss it together and try to
reach consensus. Consensus being the key word.
> I don't see the difference. In both cases, the public knows about the
> problem. It's not too hard to subscribe to Beonex's announce mailing
> list and then assume that the same bug is in all derivates of Mozilla,
> especially when I say that the bug is not Beonex-specific (just like
> Debian does in its notices). Crackers are not *that* dumb.
A determined cracker can find the exploit himself. The source code is
open, after all. We can't prevent that. What we can prevent is script
kiddies searching Bugzilla for ways to wreak havoc. That is our main
goal. 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.
>
>> The latter will discourage many vendors from participating at all,
>> enough so that the security group will become pointless.
>
>
> Can you explain why? I see absolutely no rationale. (Other than bad PR
> maybe, which I don't think will happen or consider a valid reason in
> this case.)
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.
>
>> I would argue that everyone who needs to know about the bug will still
>> have access to it through their representative on the security group.
>
>
> Depends on how you define "know". Or am I allowed to mention details ot
> the bug to a customer?
Forgive me for being imprecise. Let me revise that. "everyone who needs
to be protected from an exploit will be protected." 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.
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.
> If I may issue vage warnings (but a bit more concrete than what Frank
> described) and workarounds at any time
again, the criteria is "vague enough so that an attacker cannot
reproduce the exploit from your description."
> and may publically speak about
> what happens in the security group (but not mention specific exploits or
> details about a bug itself), then yes, this is what is acceptable to me
> as a distributor.
There's a difference between 'publicly' and 'with your own customers.' 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.
>
> But this does not mean that it is the right thing to do for Mozilla in
> general or that this allows ideal treatment of security bugs. (And, in
> these indirect and abstract ways, the current proposal is IMHO no good
> for Beonex Communicator or Netscape 6 or any other Mozilla.)
>
>> The alternative is for vendors not to file vulnerabilities in Bugzilla
>> or disclose them to Mozilla.org at all.
> That remains to be seen.
Actually, you can count on that.
> I do think that a compromise could be found
> that respects more the open nature of open-source projects and the
> believes of many people (as I understood it). In the current proposal, I
> see no compromise at all.
All right then, what do you propose? How would you write the policy?
-Mitch
