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