So here's the state of things:
The master of flink-shaded now uses jackson 2.10.1, which eliminates a
whole category of security vulnerabilities.
The flink master works perfectly fine with that version; 1.9 will likely
do so too and 1.8 would require a minor adjustment.
Hence, there may be value in first doing a flink-shaded release so we
can eliminate these vulnerabilities in 1.8.3 and 1.9.2 .
As for other jackson dependencies (coming from calcite, kafka, kinesis),
I ran the unit and end-to-end tests of master yesterday will /all
/jackson dependencies set to 2.10.1, and they passed. I will open a PR
soon-ish for making this change on master.
The question now is whether we want to backport this change to 1.8/1.9 .
Some code paths /may /not be covered by our tests, and transitive
jackson users /might /run into issues.
Alternatively, we could set this up as an opt-in upgrade, by adding a
separate profile that bumps the versions. This would present
users/providers who are concerned about the vulnerabilities an easy
workaround, at the risk of /some /things /maybe /not working.
On 14/11/2019 03:16, Hequn Cheng wrote:
Hi Chesnay, Jincheng
Sure, I think it's good to have these fixes.
Thanks a lot for providing the information about the security
vulnerabilities! @Chesnay
Best, Hequn
On Thu, Nov 14, 2019 at 10:07 AM jincheng sun <sunjincheng...@gmail.com>
wrote:
+1 for try to eliminate the security vulnerabilities. Great thanks for
doing this important work, Chesnay!
What do you think Hequn ?
Best,
Jincheng
Chesnay Schepler <ches...@apache.org> 于2019年11月13日周三 下午5:17写道：
It would be great if you could give me a day or 2 to check how easy it
would be to bump the various jackson dependencies to eliminate a few
security vulnerabilities.
On 09/11/2019 05:10, jincheng sun wrote:
Hi Flink devs,
It has been more than 2 months since the 1.8.2 released. So, What do
you
think about releasing Flink 1.8.3 soon?
We already have many important bug fixes in the release-1.8 branch (29
resolved issues).
Most notable fixes are:
- FLINK-14010 Dispatcher & JobManagers don't give up leadership when AM
is
shut down
- FLINK-14315 NPE with JobMaster.disconnectTaskManager
- FLINK-12848 Method equals() in RowTypeInfo should consider
fieldsNames
- FLINK-12342 Yarn Resource Manager Acquires Too Many Containers
- FLINK-14589 Redundant slot requests with the same AllocationID leads
to
inconsistent slot table
Furthermore, the following critical issues is in progress, maybe we can
wait for it if it is not too much effort.
- FLINK-13184 Starting a TaskExecutor blocks the YarnResourceManager's
main
thread
Please let me know what you think?
Best,
Jincheng
