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 <[email protected]> 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. >
