couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hall <fli...@flimzy.com>
Subject Re: [PROPOSAL] Future security announcement policy
Date Fri, 22 May 2020 11:48:27 GMT
An alternative, if we think this is somehow too revealing, would be to 
include a generic "This may contain security-related fixes" blurb in 
_every_ release announcement, to serve as a constant reminder that 
upgrading to the latest patch version is always wise.

That said, I'm in favor of the proposed change. Anyone serious about 
exploiting security holes will already know, by watching the code 
changes, so I see the upside of informing potential victims as much 
higher than any possible downside of informing bad actors.

Maybe I'm overlooking something, though, so I'll keep my vote to +0 for now.

Jonathan


On 5/22/20 1:43 PM, 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