+1 for the proposal and creating a quick release. Regards, Dian
On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <k...@tabular.io> wrote: > +1 to doing a release for this widely publicized vulnerability. > > In my experience, users will often update to the latest minor patch version > without much fuss. Plus, users have also likely heard about this and will > appreciate a simple fix (updating their version where possible). > > The work-around will need to still be noted for users who can’t upgrade for > whatever reason (EMR hasn’t caught up, etc). > > I also agree with your assessment to apply a patch on each of those > previous versions with only the log4j commit, so that they don’t need to be > as rigorously tested. > > Best, > Kyle (GitHub @kbendick) > > On Sun, Dec 12, 2021 at 2:23 PM Stephan Ewen <se...@apache.org> wrote: > > > Hi all! > > > > Without doubt, you heard about the log4j vulnerability [1]. > > > > There is an advisory blog post on how to mitigate this in Apache Flink > [2], > > which involves setting a config option and restarting the processes. That > > is fortunately a relatively simple fix. > > > > Despite this workaround, I think we should do an immediate release with > the > > updated dependency. Meaning not waiting for the next bug fix releases > > coming in a few weeks, but releasing asap. > > The mood I perceive in the industry is pretty much panicky over this, > and I > > expect we will see many requests for a patched release and many > discussions > > why the workaround alone would not be enough due to certain guidelines. > > > > I suggest that we preempt those discussions and create releases the > > following way: > > > > - we take the latest already released versions from each release > branch: > > ==> 1.14.0, 1.13.3, 1.12.5, 1.11.4 > > - we add a single commit to those that just updates the log4j > dependency > > - we release those as 1.14.1, 1.13.4, 1.12.6, 1.11.5, etc. > > - that way we don't need to do functional release tests, because the > > released code is identical to the previous release, except for the log4j > > dependency > > - we can then continue the work on the upcoming bugfix releases as > > planned, without high pressure > > > > I would suggest creating those RCs immediately and release them with a > > special voting period (24h or so). > > > > WDYT? > > > > Best, > > Stephan > > > > [1] https://nvd.nist.gov/vuln/detail/CVE-2021-44228 > > [2] https://flink.apache.org/2021/12/10/log4j-cve.html > > >
