You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flink.apache.org by Stephan Ewen <se...@apache.org> on 2021/12/12 22:23:16 UTC
[DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
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
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Prasanna kumar <pr...@gmail.com>.
It would be good if docker images are released too .
Prasanna.
On Mon, 13 Dec 2021, 16:16 Jing Zhang, <be...@gmail.com> wrote:
> +1 for the quick release.
>
> Till Rohrmann <tr...@apache.org> 于2021年12月13日周一 17:54写道：
>
> > +1
> >
> > Cheers,
> > Till
> >
> > On Mon, Dec 13, 2021 at 10:42 AM Jing Ge <ji...@ververica.com> wrote:
> >
> > > +1
> > >
> > > As I suggested to publish the blog post last week asap, users have been
> > > keen to have such urgent releases. Many thanks for it.
> > >
> > >
> > >
> > > On Mon, Dec 13, 2021 at 8:29 AM Konstantin Knauf <kn...@apache.org>
> > > wrote:
> > >
> > > > +1
> > > >
> > > > I didn't think this was necessary when I published the blog post on
> > > Friday,
> > > > but this has made higher waves than I expected over the weekend.
> > > >
> > > >
> > > >
> > > > On Mon, Dec 13, 2021 at 8:23 AM Yuan Mei <yu...@gmail.com>
> > wrote:
> > > >
> > > > > +1 for quick release.
> > > > >
> > > > > On Mon, Dec 13, 2021 at 2:55 PM Martijn Visser <
> > martijn@ververica.com>
> > > > > wrote:
> > > > >
> > > > > > +1 to address the issue like this
> > > > > >
> > > > > > On Mon, 13 Dec 2021 at 07:46, Jingsong Li <
> jingsonglee0@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > +1 for fixing it in these versions and doing quick releases.
> > Looks
> > > > good
> > > > > > to
> > > > > > > me.
> > > > > > >
> > > > > > > Best,
> > > > > > > Jingsong
> > > > > > >
> > > > > > > On Mon, Dec 13, 2021 at 2:18 PM Becket Qin <
> becket.qin@gmail.com
> > >
> > > > > wrote:
> > > > > > > >
> > > > > > > > +1. The solution sounds good to me. There have been a lot of
> > > > > inquiries
> > > > > > > > about how to react to this.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Jiangjie (Becket) Qin
> > > > > > > >
> > > > > > > > On Mon, Dec 13, 2021 at 12:40 PM Prasanna kumar <
> > > > > > > > prasannakumarramani@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > 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 <
> > xbjtdcq@gmail.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > +1 for the quick release and the special vote period 24h.
> > > > > > > > > >
> > > > > > > > > > > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com>
> 写道：
> > > > > > > > > > >
> > > > > > > > > > > +1 for the proposal and creating a quick release.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > > Dian
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <
> > > > > > kyle@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 <
> > > > > sewen@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
> > > > > > > > > > >>>
> > > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Best, Jingsong Lee
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > >
> > > > Konstantin Knauf
> > > >
> > > > https://twitter.com/snntrable
> > > >
> > > > https://github.com/knaufk
> > > >
> > >
> >
>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Jing Zhang <be...@gmail.com>.
+1 for the quick release.
Till Rohrmann <tr...@apache.org> 于2021年12月13日周一 17:54写道：
> +1
>
> Cheers,
> Till
>
> On Mon, Dec 13, 2021 at 10:42 AM Jing Ge <ji...@ververica.com> wrote:
>
> > +1
> >
> > As I suggested to publish the blog post last week asap, users have been
> > keen to have such urgent releases. Many thanks for it.
> >
> >
> >
> > On Mon, Dec 13, 2021 at 8:29 AM Konstantin Knauf <kn...@apache.org>
> > wrote:
> >
> > > +1
> > >
> > > I didn't think this was necessary when I published the blog post on
> > Friday,
> > > but this has made higher waves than I expected over the weekend.
> > >
> > >
> > >
> > > On Mon, Dec 13, 2021 at 8:23 AM Yuan Mei <yu...@gmail.com>
> wrote:
> > >
> > > > +1 for quick release.
> > > >
> > > > On Mon, Dec 13, 2021 at 2:55 PM Martijn Visser <
> martijn@ververica.com>
> > > > wrote:
> > > >
> > > > > +1 to address the issue like this
> > > > >
> > > > > On Mon, 13 Dec 2021 at 07:46, Jingsong Li <ji...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > +1 for fixing it in these versions and doing quick releases.
> Looks
> > > good
> > > > > to
> > > > > > me.
> > > > > >
> > > > > > Best,
> > > > > > Jingsong
> > > > > >
> > > > > > On Mon, Dec 13, 2021 at 2:18 PM Becket Qin <becket.qin@gmail.com
> >
> > > > wrote:
> > > > > > >
> > > > > > > +1. The solution sounds good to me. There have been a lot of
> > > > inquiries
> > > > > > > about how to react to this.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Jiangjie (Becket) Qin
> > > > > > >
> > > > > > > On Mon, Dec 13, 2021 at 12:40 PM Prasanna kumar <
> > > > > > > prasannakumarramani@gmail.com> wrote:
> > > > > > >
> > > > > > > > 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 <
> xbjtdcq@gmail.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > +1 for the quick release and the special vote period 24h.
> > > > > > > > >
> > > > > > > > > > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
> > > > > > > > > >
> > > > > > > > > > +1 for the proposal and creating a quick release.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Dian
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <
> > > > > kyle@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 <
> > > > sewen@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
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best, Jingsong Lee
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Konstantin Knauf
> > >
> > > https://twitter.com/snntrable
> > >
> > > https://github.com/knaufk
> > >
> >
>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Ada Luna <gf...@gmail.com>.
+1
I need 1.12.6, thanks
Till Rohrmann <tr...@apache.org> 于2021年12月13日周一 17:54写道：
>
> +1
>
> Cheers,
> Till
>
> On Mon, Dec 13, 2021 at 10:42 AM Jing Ge <ji...@ververica.com> wrote:
>
> > +1
> >
> > As I suggested to publish the blog post last week asap, users have been
> > keen to have such urgent releases. Many thanks for it.
> >
> >
> >
> > On Mon, Dec 13, 2021 at 8:29 AM Konstantin Knauf <kn...@apache.org>
> > wrote:
> >
> > > +1
> > >
> > > I didn't think this was necessary when I published the blog post on
> > Friday,
> > > but this has made higher waves than I expected over the weekend.
> > >
> > >
> > >
> > > On Mon, Dec 13, 2021 at 8:23 AM Yuan Mei <yu...@gmail.com> wrote:
> > >
> > > > +1 for quick release.
> > > >
> > > > On Mon, Dec 13, 2021 at 2:55 PM Martijn Visser <ma...@ververica.com>
> > > > wrote:
> > > >
> > > > > +1 to address the issue like this
> > > > >
> > > > > On Mon, 13 Dec 2021 at 07:46, Jingsong Li <ji...@gmail.com>
> > > > wrote:
> > > > >
> > > > > > +1 for fixing it in these versions and doing quick releases. Looks
> > > good
> > > > > to
> > > > > > me.
> > > > > >
> > > > > > Best,
> > > > > > Jingsong
> > > > > >
> > > > > > On Mon, Dec 13, 2021 at 2:18 PM Becket Qin <be...@gmail.com>
> > > > wrote:
> > > > > > >
> > > > > > > +1. The solution sounds good to me. There have been a lot of
> > > > inquiries
> > > > > > > about how to react to this.
> > > > > > >
> > > > > > > Thanks,
> > > > > > >
> > > > > > > Jiangjie (Becket) Qin
> > > > > > >
> > > > > > > On Mon, Dec 13, 2021 at 12:40 PM Prasanna kumar <
> > > > > > > prasannakumarramani@gmail.com> wrote:
> > > > > > >
> > > > > > > > 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 <xb...@gmail.com>
> > > > > wrote:
> > > > > > > >
> > > > > > > > > +1 for the quick release and the special vote period 24h.
> > > > > > > > >
> > > > > > > > > > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
> > > > > > > > > >
> > > > > > > > > > +1 for the proposal and creating a quick release.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > > Dian
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <
> > > > > kyle@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 <
> > > > sewen@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
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Best, Jingsong Lee
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > >
> > > Konstantin Knauf
> > >
> > > https://twitter.com/snntrable
> > >
> > > https://github.com/knaufk
> > >
> >
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Till Rohrmann <tr...@apache.org>.
+1
Cheers,
Till
On Mon, Dec 13, 2021 at 10:42 AM Jing Ge <ji...@ververica.com> wrote:
> +1
>
> As I suggested to publish the blog post last week asap, users have been
> keen to have such urgent releases. Many thanks for it.
>
>
>
> On Mon, Dec 13, 2021 at 8:29 AM Konstantin Knauf <kn...@apache.org>
> wrote:
>
> > +1
> >
> > I didn't think this was necessary when I published the blog post on
> Friday,
> > but this has made higher waves than I expected over the weekend.
> >
> >
> >
> > On Mon, Dec 13, 2021 at 8:23 AM Yuan Mei <yu...@gmail.com> wrote:
> >
> > > +1 for quick release.
> > >
> > > On Mon, Dec 13, 2021 at 2:55 PM Martijn Visser <ma...@ververica.com>
> > > wrote:
> > >
> > > > +1 to address the issue like this
> > > >
> > > > On Mon, 13 Dec 2021 at 07:46, Jingsong Li <ji...@gmail.com>
> > > wrote:
> > > >
> > > > > +1 for fixing it in these versions and doing quick releases. Looks
> > good
> > > > to
> > > > > me.
> > > > >
> > > > > Best,
> > > > > Jingsong
> > > > >
> > > > > On Mon, Dec 13, 2021 at 2:18 PM Becket Qin <be...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > +1. The solution sounds good to me. There have been a lot of
> > > inquiries
> > > > > > about how to react to this.
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Jiangjie (Becket) Qin
> > > > > >
> > > > > > On Mon, Dec 13, 2021 at 12:40 PM Prasanna kumar <
> > > > > > prasannakumarramani@gmail.com> wrote:
> > > > > >
> > > > > > > 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 <xb...@gmail.com>
> > > > wrote:
> > > > > > >
> > > > > > > > +1 for the quick release and the special vote period 24h.
> > > > > > > >
> > > > > > > > > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
> > > > > > > > >
> > > > > > > > > +1 for the proposal and creating a quick release.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Dian
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <
> > > > kyle@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 <
> > > sewen@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
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best, Jingsong Lee
> > > > >
> > > >
> > >
> >
> >
> > --
> >
> > Konstantin Knauf
> >
> > https://twitter.com/snntrable
> >
> > https://github.com/knaufk
> >
>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Jing Ge <ji...@ververica.com>.
+1
As I suggested to publish the blog post last week asap, users have been
keen to have such urgent releases. Many thanks for it.
On Mon, Dec 13, 2021 at 8:29 AM Konstantin Knauf <kn...@apache.org> wrote:
> +1
>
> I didn't think this was necessary when I published the blog post on Friday,
> but this has made higher waves than I expected over the weekend.
>
>
>
> On Mon, Dec 13, 2021 at 8:23 AM Yuan Mei <yu...@gmail.com> wrote:
>
> > +1 for quick release.
> >
> > On Mon, Dec 13, 2021 at 2:55 PM Martijn Visser <ma...@ververica.com>
> > wrote:
> >
> > > +1 to address the issue like this
> > >
> > > On Mon, 13 Dec 2021 at 07:46, Jingsong Li <ji...@gmail.com>
> > wrote:
> > >
> > > > +1 for fixing it in these versions and doing quick releases. Looks
> good
> > > to
> > > > me.
> > > >
> > > > Best,
> > > > Jingsong
> > > >
> > > > On Mon, Dec 13, 2021 at 2:18 PM Becket Qin <be...@gmail.com>
> > wrote:
> > > > >
> > > > > +1. The solution sounds good to me. There have been a lot of
> > inquiries
> > > > > about how to react to this.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jiangjie (Becket) Qin
> > > > >
> > > > > On Mon, Dec 13, 2021 at 12:40 PM Prasanna kumar <
> > > > > prasannakumarramani@gmail.com> wrote:
> > > > >
> > > > > > 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 <xb...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > +1 for the quick release and the special vote period 24h.
> > > > > > >
> > > > > > > > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
> > > > > > > >
> > > > > > > > +1 for the proposal and creating a quick release.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Dian
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <
> > > kyle@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 <
> > sewen@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
> > > > > > > >>>
> > > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Best, Jingsong Lee
> > > >
> > >
> >
>
>
> --
>
> Konstantin Knauf
>
> https://twitter.com/snntrable
>
> https://github.com/knaufk
>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Konstantin Knauf <kn...@apache.org>.
+1
I didn't think this was necessary when I published the blog post on Friday,
but this has made higher waves than I expected over the weekend.
On Mon, Dec 13, 2021 at 8:23 AM Yuan Mei <yu...@gmail.com> wrote:
> +1 for quick release.
>
> On Mon, Dec 13, 2021 at 2:55 PM Martijn Visser <ma...@ververica.com>
> wrote:
>
> > +1 to address the issue like this
> >
> > On Mon, 13 Dec 2021 at 07:46, Jingsong Li <ji...@gmail.com>
> wrote:
> >
> > > +1 for fixing it in these versions and doing quick releases. Looks good
> > to
> > > me.
> > >
> > > Best,
> > > Jingsong
> > >
> > > On Mon, Dec 13, 2021 at 2:18 PM Becket Qin <be...@gmail.com>
> wrote:
> > > >
> > > > +1. The solution sounds good to me. There have been a lot of
> inquiries
> > > > about how to react to this.
> > > >
> > > > Thanks,
> > > >
> > > > Jiangjie (Becket) Qin
> > > >
> > > > On Mon, Dec 13, 2021 at 12:40 PM Prasanna kumar <
> > > > prasannakumarramani@gmail.com> wrote:
> > > >
> > > > > 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 <xb...@gmail.com>
> > wrote:
> > > > >
> > > > > > +1 for the quick release and the special vote period 24h.
> > > > > >
> > > > > > > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
> > > > > > >
> > > > > > > +1 for the proposal and creating a quick release.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Dian
> > > > > > >
> > > > > > >
> > > > > > > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <
> > kyle@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 <
> sewen@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
> > > > > > >>>
> > > > > > >>
> > > > > >
> > > > > >
> > > > >
> > >
> > >
> > >
> > > --
> > > Best, Jingsong Lee
> > >
> >
>
--
Konstantin Knauf
https://twitter.com/snntrable
https://github.com/knaufk
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Yuan Mei <yu...@gmail.com>.
+1 for quick release.
On Mon, Dec 13, 2021 at 2:55 PM Martijn Visser <ma...@ververica.com>
wrote:
> +1 to address the issue like this
>
> On Mon, 13 Dec 2021 at 07:46, Jingsong Li <ji...@gmail.com> wrote:
>
> > +1 for fixing it in these versions and doing quick releases. Looks good
> to
> > me.
> >
> > Best,
> > Jingsong
> >
> > On Mon, Dec 13, 2021 at 2:18 PM Becket Qin <be...@gmail.com> wrote:
> > >
> > > +1. The solution sounds good to me. There have been a lot of inquiries
> > > about how to react to this.
> > >
> > > Thanks,
> > >
> > > Jiangjie (Becket) Qin
> > >
> > > On Mon, Dec 13, 2021 at 12:40 PM Prasanna kumar <
> > > prasannakumarramani@gmail.com> wrote:
> > >
> > > > 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 <xb...@gmail.com>
> wrote:
> > > >
> > > > > +1 for the quick release and the special vote period 24h.
> > > > >
> > > > > > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
> > > > > >
> > > > > > +1 for the proposal and creating a quick release.
> > > > > >
> > > > > > Regards,
> > > > > > Dian
> > > > > >
> > > > > >
> > > > > > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <
> kyle@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
> > > > > >>>
> > > > > >>
> > > > >
> > > > >
> > > >
> >
> >
> >
> > --
> > Best, Jingsong Lee
> >
>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Martijn Visser <ma...@ververica.com>.
+1 to address the issue like this
On Mon, 13 Dec 2021 at 07:46, Jingsong Li <ji...@gmail.com> wrote:
> +1 for fixing it in these versions and doing quick releases. Looks good to
> me.
>
> Best,
> Jingsong
>
> On Mon, Dec 13, 2021 at 2:18 PM Becket Qin <be...@gmail.com> wrote:
> >
> > +1. The solution sounds good to me. There have been a lot of inquiries
> > about how to react to this.
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> > On Mon, Dec 13, 2021 at 12:40 PM Prasanna kumar <
> > prasannakumarramani@gmail.com> wrote:
> >
> > > 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 <xb...@gmail.com> wrote:
> > >
> > > > +1 for the quick release and the special vote period 24h.
> > > >
> > > > > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
> > > > >
> > > > > +1 for the proposal and creating a quick release.
> > > > >
> > > > > Regards,
> > > > > Dian
> > > > >
> > > > >
> > > > > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <ky...@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
> > > > >>>
> > > > >>
> > > >
> > > >
> > >
>
>
>
> --
> Best, Jingsong Lee
>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Jingsong Li <ji...@gmail.com>.
+1 for fixing it in these versions and doing quick releases. Looks good to me.
Best,
Jingsong
On Mon, Dec 13, 2021 at 2:18 PM Becket Qin <be...@gmail.com> wrote:
>
> +1. The solution sounds good to me. There have been a lot of inquiries
> about how to react to this.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
> On Mon, Dec 13, 2021 at 12:40 PM Prasanna kumar <
> prasannakumarramani@gmail.com> wrote:
>
> > 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 <xb...@gmail.com> wrote:
> >
> > > +1 for the quick release and the special vote period 24h.
> > >
> > > > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
> > > >
> > > > +1 for the proposal and creating a quick release.
> > > >
> > > > Regards,
> > > > Dian
> > > >
> > > >
> > > > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <ky...@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
> > > >>>
> > > >>
> > >
> > >
> >
--
Best, Jingsong Lee
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Becket Qin <be...@gmail.com>.
+1. The solution sounds good to me. There have been a lot of inquiries
about how to react to this.
Thanks,
Jiangjie (Becket) Qin
On Mon, Dec 13, 2021 at 12:40 PM Prasanna kumar <
prasannakumarramani@gmail.com> wrote:
> 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 <xb...@gmail.com> wrote:
>
> > +1 for the quick release and the special vote period 24h.
> >
> > > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
> > >
> > > +1 for the proposal and creating a quick release.
> > >
> > > Regards,
> > > Dian
> > >
> > >
> > > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <ky...@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
> > >>>
> > >>
> >
> >
>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Prasanna kumar <pr...@gmail.com>.
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 <xb...@gmail.com> wrote:
> +1 for the quick release and the special vote period 24h.
>
> > 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
> >
> > +1 for the proposal and creating a quick release.
> >
> > Regards,
> > Dian
> >
> >
> > On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <ky...@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
> >>>
> >>
>
>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Leonard Xu <xb...@gmail.com>.
+1 for the quick release and the special vote period 24h.
> 2021年12月13日 上午11:49，Dian Fu <di...@gmail.com> 写道：
>
> +1 for the proposal and creating a quick release.
>
> Regards,
> Dian
>
>
> On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <ky...@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
>>>
>>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Dian Fu <di...@gmail.com>.
+1 for the proposal and creating a quick release.
Regards,
Dian
On Mon, Dec 13, 2021 at 11:15 AM Kyle Bendickson <ky...@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
> >
>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Kyle Bendickson <ky...@tabular.io>.
+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
>
Re: [DISCUSS] Immediate dedicated Flink releases for log4j vulnerability
Posted by Chesnay Schepler <ch...@apache.org>.
I will start preparing the release candidates.
On 12/12/2021 23:23, Stephan Ewen 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
>