Fixing security vulnerabilities: CVE-2021-37137, CVE-2021-37136, CVE-2020-28491, CVE-2020-25649, CVE-2021-43797, CVE-2018-10237, CVE-2020-13956

[junkeiro]

Below can be found the table with more description of these security vulnerabilities:

CVE	Package	Version	Severity	Status
CVE-2021-37137	io.netty_netty-codec	4.1.66.Final	high	fixed in 4.1.68
CVE-2021-37136	io.netty_netty-codec	4.1.66.Final	high	fixed in 4.1.68
CVE-2020-28491	com.fasterxml.jackson.dataformat_jackson-dataformat-cbor	2.10.4	high	fixed in 2.11.4, 2.12.1
CVE-2020-25649	com.fasterxml.jackson.core_jackson-databind	2.10.4	high	fixed in 2.10.5.1, 2.9.10.7, 2
CVE-2021-43797	io.netty_netty-codec	4.1.66.Final	medium	fixed in 4.1.71
CVE-2018-10237	com.google.guava_guava	19	medium	fixed in 24.1.1
CVE-2020-13956	org.apache.httpcomponents_httpclient	4.5.10	medium	fixed in 5.0.3, 4.5.13

[tvernum]

Hi @junkeiro, thanks for your interest in Elasticsearch.

Unfortunately we can't really move forwards with the PR as it currently stands for a number of reasons:

• This PR is targeting 7.16, but all PRs need to target the master branch, unless they resolve an issue that is only present in an earlier version (in which case they need to target the highest branch with that issue)
• The 7.16 branch is a stable, bugfix-only branch. We do perform dependency upgrades in patch (bug fix) releases, but only when there are specific justifications for why that dependency need to be upgraded urgently in a bug fix.
• PRs to upgrade dependencies should target a single dependency at a time (or a complete set of transitive dependencies), so they can be assessed and tested on a case-by-case basis. Some of the dependencies in this PR are unrelated and ought to be handled in separate PRs
• Some of the upgrades you are proposing will break compatibility. For example, we depend on Guava 19 because that is the precise Guava version that OpenSAML depends on. It is not safe to upgrade it to a newer major version without understanding the inter-dependencies.

If you would like to pick one of those libraries and open a PR against master that updates the dependency version, then we will be able to review that.
Be aware though that there are often complex reasons why certain versions cannot be upgraded, and some upgrades require significant work. See for example #73861 and #77012
Updating the version number in version.properties is step 1, after that there can be many steps to investigate test failures, performance degradations and potential incompatibilities across transitive dependencies.

[junkeiro]

Got it totally, I'm sending a new PR with only jackson version being changed, and creating the PR against master branch.