Mailing-List: contact ooo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ooo-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of apache@robweir.com designates
 67.222.55.9 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CALRLYEm3ffyun2xYRHMm=x1cJ5c3LK18hM0MfHAcL8+4ivXk3A@mail.gmail.com>
References: <000f01cc4cc4$f5e29530$e1a7bf90$@apache.org>
	<CAP-ksogT0FTmLkPnOAi2tesMKEEA2jdw7=Qrv7OdD77c4nBwaw@mail.gmail.com>
	<00b201cc4d61$9a323590$ce96a0b0$@apache.org>
	<4E31D790.8050409@documentfoundation.org>
	<010501cc4d77$cb0e9800$612bc800$@acm.org>
	<CALRLYEm3ffyun2xYRHMm=x1cJ5c3LK18hM0MfHAcL8+4ivXk3A@mail.gmail.com>
Date: Thu, 28 Jul 2011 19:23:28 -0400
Message-ID: 
 <CAP-ksohhTQXourMy+6E138jadBhqz5_4V3e_MaBhJXJfG5j1zA@mail.gmail.com>
Subject: Re: RE: Population of ooo-security
From: Rob Weir <apache@robweir.com>
To: ooo-dev@incubator.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Jul 28, 2011 at 6:59 PM, Wolf Halton <wolf.halton@gmail.com> wrote:
> One of the things I think proprietary projects are wrong about is treatin=
g
> bugs, including security bugs, as secret private things. The best securit=
y
> solution we have is the number of eyes we allow to see the problems. I th=
ink
> emulating the paranoia is a mistake. Security-related bugs should go to t=
he
> bug squashing system all bugs go to. Triage and fixes can then follow, an=
d
> the more security-skilled coders can take it from there.
>
> Just my .02=C2=A2
>

Two kinds of vulnerabilities:

1) Those that are newly discovered by this project itself, or by a
responsible third party that has reported it to us. The vulnerability
may be serious, but the threat is still latent because the bad guys
don't know about it yet.  But there is some urgency to fix the issue,
because the bad guys will find out soon eventually.

2) Those vulnerabilities that come to our attention only after they
are actively being used in an attack, the so called  zero-day exploit.

I think in case #2, there is no great reason to keep it a secret. The
"cat is out of the bag" already.  But in case #1, and that is the most
common case, I think it is absolutely critical to keep the
vulnerability from becoming public information until the project has
published a patch.  At that time there are standards for reporting the
vulnerability so customers have a fair shot at hearing about the
problem and patching their systems before the bad guys have time to
deploy an exploit based on the vulnerability.  Once the information is
public, it is a race, between users/admins and the bad guys.  Our job,
in an open source project, is to do whatever we can to make sure the
users/admins have a chance to win.

I would agree with you that security related code should be public and
discussed in public.  That is one advantage that open source has.  We
can have many eyes review our code.  But when you have a report of an
exploitable vulnerability, that is something else.  At that point a
race has started.  Will we patch the issue before someone exploits it?
 Or will the black hats win?

-Rob