incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <apa...@robweir.com>
Subject Re: Population of ooo-security
Date Fri, 29 Jul 2011 01:25:24 GMT
On Thu, Jul 28, 2011 at 7:51 PM, Dave Fisher <dave2wave@comcast.net> wrote:
>
> On Jul 28, 2011, at 4:23 PM, Rob Weir wrote:
>
>> 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 treating
>>> bugs, including security bugs, as secret private things. The best security
>>> solution we have is the number of eyes we allow to see the problems. I think
>>> emulating the paranoia is a mistake. Security-related bugs should go to the
>>> bug squashing system all bugs go to. Triage and fixes can then follow, and
>>> the more security-skilled coders can take it from there.
>>>
>>> Just my .02¢
>>>
>>
>> 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?
>
> Have a look at the Apache Tomcat Security page: http://tomcat.apache.org/security.html
>
> Here is what is said about their security mail list in boldface type.
>
>> Please note that the security mailing list should only be used for reporting undisclosed
security vulnerabilities in Apache Tomcat and managing the process of fixing such vulnerabilities.
We cannot accept regular bug reports or other queries at this address. All mail sent to this
address that does not relate to an undisclosed security problem in the Apache Tomcat source
code will be ignored.
>

I've seen that language elsewhere.  For example, the main Apache
security page [1] says:

"Please note that the security mailing lists should only be used for
reporting undisclosed security vulnerabilities in Apache products and
managing the process of fixing such vulnerabilities. We cannot accept
regular bug reports or other security related queries at these
addresses. All mail sent to these addresses that does not relate to an
undisclosed security problem in an Apache product will be ignored."

However, that same page also says, "The Apache Security Team exists to
provide help and advice to Apache projects on security issues and to
provide co-ordination of the handling of security vulnerabilities. All
members of the Security Team are also members of the Apache Software
Foundation."

That raises some questions:

A) How does one engage with the Apache Security team for "help and
advice to Apache projects on security issues" if any mail that "does
not relate to an undisclosed security problem in an Apache product
will be ignored".  Is there another list we should be asking
process-related questions?

B) Why is is the significance of their statement, "All members of the
Security Team are also members of the Apache Software Foundation".
That means that they can vote for members of the Apache Board, right?
Why is that significant for the security?


[1] http://www.apache.org/security/


> It is interesting to see the type of information about each CVE and the fixes on three
different Tomcat versions.
>
> Regards,
> Dave

Mime
View raw message