1+ for making Updates for 1.12.5 . We are looking for fix in 1.12 version. Please notify once the fix is done.
On Mon, Dec 13, 2021 at 9:45 AM Leonard Xu <xbjt...@gmail.com> wrote: > +1 for the quick release and the special vote period 24h. > > > 2021年12月13日 上午11:49，Dian Fu <dian0511...@gmail.com> 写道： > > > > +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 > >>> > >> > >
