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