I'm curious what the Apache Security team's opinion is on this (they are
cc'ed on every email to secur...@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 <rnew...@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.
