We've done concurrent releases without security before, and you follow much closer than others. I feel most people, if they saw all of the changes reverted and a release of a single fix, would either instantly know it's security (high confidence pointer to exactly which patch) OR assume someone botched the release prep and draw attention to it. So we're trading "someone who's very involved has a high confidence it's security but has to dig through 30 patches to find it" vs "everyone knows exactly what's going on", the former seems better
The only way I'd be in favor of a release that removes all other committed patches is if the vote happened in private@ . I don't see any prohibition on that in https://www.apache.org/foundation/voting.html#ReleaseVotes , so that seems like an alternate, easy workaround to privacy. On Tue, Feb 15, 2022 at 7:42 AM J. D. Jordan <jeremiah.jor...@gmail.com> wrote: > 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. > >
