The first question I have is: Is anyone running 1.3.0 in production today?
That release is over a year old and there are many known problems that have been fixed on 1.4.0. I would be quite surprised if anyone is running 1.3.0 successfully without some additional custom patches on top of it. If they have a patched 1.3.0, then a new release won't help, as it would be easier to just cherry pick the CVE fix on top of their custom build. On Mon, Feb 12, 2024 at 10:39 AM István Fajth <fapi...@gmail.com> wrote: > Hi developers, > > Me and Attila had a discussion about a PR > <https://github.com/apache/ozone/pull/6100> that is posted by @ivandika3. > > In our SECURITY.md file we have a table about our supported versions. > In light of the recent CVE, the idea is to remove the supported flag from > any release prior to 1.3.0, and leave 1.3.0 and 1.4.0 supported. > > I tend to believe this is something that is reasonable considering that > 1.2.1 is over 2 years old. > > However, leaving 1.3.0 supported means that we should release 1.3.1 in > order to have the recently released CVE-2023-39196 fixed for the 1.3.x > line. > There was an effort earlier to release 1.3.1, but we have abandoned that > effort. > > *What do you think, which way should we manage this?* > 1. Leave 1.3.1 branch as it is cherry-pick the CVE fix, and release it? > 2. Leave 1.3.1 alone, and release the fix for the CVE from a new branch as > (a) 1.3.0.1, or (b)1.3.2? > 3. Prepare a proper 1.3.1 release with all the critical fixes that we have, > including the fix for the CVE? > 4. Mark 1.3.0 unsupported which is also something that I can imagine, > however that release is just over 1 year old. > > A minimalistic approach - As we dropped the idea of 1.3.1 already - to just > go with 2a. > The simplest is to choose to drop support for 1.3.0. > If we support 1.3.0 today, and we want to do it right, then releasing 1.3.1 > in the next 1-2 weeks seems to be the proper approach. > > I am +1 for all these 3 approaches and I am not against the approach listed > in point 1., however I do not support it either. > I can not - at the moment - take on a full 1.3.1 release, so if the > community decides to go that route, we will need a release manager also for > that. > > What I can volunteer for, is to update the SECURITY.md based on the > decision, and in case a minimalistic release approach is taken (2a or 2b), > I can take on releasing that. > > -- > Pifta >
