+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 >
