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