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