couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: [PROPOSAL] Future security announcement policy
Date Fri, 22 May 2020 12:32:58 GMT


> On 22. May 2020, at 13:48, Jonathan Hall <flimzy@flimzy.com> wrote:
> 
> 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

This reminded me of something. For a particularly egregious vulnerability that we absolutely
do not want to make public in advance, we have a fallback variant of making a release off
of a private branch. We have used this once in the past. Give that we have that fallback,
I’m +0.5 on making the change :)

I’m not sure the “might” message would do much good.

Best
Jan
–



> , 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