couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Samuel Newson <>
Subject Re: [PROPOSAL] Future security announcement policy
Date Fri, 22 May 2020 17:32:28 GMT

I side with Jan that the "we've always got security patches in every release" idea is pointless.
The purpose of this thread is whether we should tell users that a release has a security fix,
to encourage them to upgrade urgently.

Unless we can hide security commits entirely until the release is published, there's only
shades of grey here. All our security related fixes are visible for days or weeks ahead of
any release. We don't draw attention to them, and erlang is a dark and obscure art (if done
correctly), but even so, they are public.

I take your point, and Mark's, but I do think it's a little optimistic to think that folks
aren't looking at the commits as they happen, and scrutinising the releases, if they are motivated
to find exploitable security issues.

That said, perhaps we can find, or invent, an ASF approved means to delay publication of security
related fixes until the release. The voting period does seem to make that impossible, though.

Is the current situation the best we, or any Apache project, can do?


> On 22 May 2020, at 18:15, Joan Touzet <> wrote:
> I'm curious what the Apache Security team's opinion is on this (they are cc'ed on every
email to
> The detailed policy for the ASF is here:
> 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,
> 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 <> wrote:
>>> Hi All,
>>> We've just published a CVE and it made me think about our current announcement
>>> 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.

View raw message