We already advertise that we are preparing a security release when ever we release all of our patch versions at the same time. So I don’t think there is an issue there. I was not involved in any PMC discussions and had no knowledge of the CVE, but when three branches got release votes at the same moment I knew one of the final couple patches that was on all three must be an un-announced CVE. It is especially more obvious when said patches mention JIRA ticket numbers with no information in the ticket. Nobody is being sneaky here as long as the vote and code are in the open.
> On Feb 15, 2022, at 9:15 AM, bened...@apache.org wrote: > > > One issue with this approach is that we are advertising that we are preparing > a security release by preparing such a release candidate. > > I wonder if we need to find a way to produce binaries without leaving an > obvious public mark (i.e. private CI, private branch) > > > From: Josh McKenzie <jmcken...@apache.org> > Date: Tuesday, 15 February 2022 at 14:09 > To: dev@cassandra.apache.org <dev@cassandra.apache.org> > Subject: [DISCUSS] Hotfix release procedure > > On the release thread for 4.0.2 Jeremiah brought up a point about hotfix > releases and CI: > https://lists.apache.org/thread/7zc22z5vw5b58hdzpx2nypwfzjzo3qbr > > If we are making this release for a security incident/data loss/hot fix > reason, then I would expect to see the related change set only containing > those patches. But the change set in the tag here the latest 4.0-dev commits. > > I'd like to propose that in the future, regardless of the state of CI, if we > need to cut a hotfix release we do so from the previous released SHA + only > the changes required to address the hotfix to minimally impact our end users > and provide them with as minimally disruptive a fix as possible.
