Thanks Mark, that’s why I asked for security@ to be CC’d here.

As Joan noted, we’d rather not maintain a separate private repo
just for security releases. While git makes it feasible, the
whole process is a bit more involved and error prone.

Either way, we will always have at least a 72 vote + 24 hour
mirroring delay where folks might notice we didn’t cut the
release from the public repo and start looking through the
RC tarballs.

If I were eager to find security issues, I’d use that time
window either way and a release announcement that explains that
there is a security issue/severity/mitigation, but not which
exactly doesn’t make much of a difference.

Am I missing something?

Best
Jan
—

> On 22. May 2020, at 19:27, Mark J Cox <m...@apache.org> wrote:
> 
> On Fri, May 22, 2020 at 6:15 PM Joan Touzet <woh...@apache.org> wrote:
> 
>> 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 policy that OpenSSL has works because OpenSSL doesn't release the
> update at the time of that prenotification and usually the fix for the
> issue isn't in the repo; instead it's handled in private with the final
> commits and tarball going live around the same time as the advisory is
> published (all within an hour or so anyway).  As stated in the thread, if
> you notify your users there is a security issue (or worse if you tell them
> it's a 'critical' one)  in a tarball you've already released then you'll
> end up with people looking through the commits to find it so they can
> publish it or exploit it and then it creates a disclosure mess which we
> would not recommend.
> 
> Regards, Mark

Reply via email to