couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <woh...@apache.org>
Subject Re: [PROPOSAL] Future security announcement policy
Date Fri, 22 May 2020 17:15:52 GMT
I'm curious what the Apache Security team's opinion is on this (they are 
cc'ed on every email to security@couchdb.apache.org).

The detailed policy for the ASF is here:

https://www.apache.org/security/committers.html

The only reference here to public/private is step 11:

 > The project team agrees the fix, the announcement and the release
 > schedule with the reporter.

And then in step 15, the vulnerability release is announced:

 > after, or at the same time as, the release announcement.

It says nothing about saying "something's coming," for or against.

The problem I see is that if people know a problem is about to be 
resolved, they will look at version control closely to see if they can 
spot what the fix is. Because the release process takes a minimum of 4 
days - 3 days for the vote to pass, and 24 hours for the mirrors to 
update - this could leave unpatched people more exposed for longer than 
they would with a "0-day".

To work around this and always give people a heads up on a release, we'd 
be forced into preparing all high-profile security releases in private. 
I did *not* enjoy when we had to do this last time (2.3.0 or 2.3.1, I 
think), and I'm sure no one else in the process did, either.

The "we've always got security patches in every release" isn't a bad 
one, but it could be a lie. We don't always fix security things. 
Personally I'd rather be honest (and surprise people with a patch) than 
lie and tell people there's patches when there aren't any.

-Joan "would like to know more from security@ first" Touzet


On 2020-05-22 7:43, Jan Lehnardt wrote:
> I like the OpenSSL announcements and their categorisation. They allow me to decide, whether
I have to pencil in an upgrade for the date of the release or not. So *if* we decide to do
this, I’d advocate to include severity and mitigation information in broad strokes at least.
> 
> I’m +0 on making the change.
> 
> Best
> Jan
> —
> 
>> On 22. May 2020, at 13:38, Robert Samuel Newson <rnewson@apache.org> wrote:
>>
>> Hi All,
>>
>> We've just published a CVE and it made me think about our current announcement policy.
>>
>> Currently, when we receive notice of a security issue, the PMC investigate it, fix
it if it's genuine, then we prepare and publish a release without mentioning the security
issue. A week after publication we publish the CVE.
>>
>> I think we can do better. I follow haproxy and openssl announcements for security
reasons and have found their early warning very helpful. I wonder if we can do something similar?
>>
>> My proposal is modest. Everything stays the same as today except we announce that
there is a security fix in the release _at the time we publish it_. The details are withheld
for the regular 7 day period.
>>
>> Are there objections to that step? Should we do more? Would it useful to categorise
the security issue (low, medium, high. whether it is present in the default config. whether
it can be mitigated without taking the upgrade)?
>>
>> B.
>>
> 

Mime
View raw message