[CVE-2020-36518] Move Jackson-databind to 2.13.2

[peternied]

Description

Security took a fix for a opensearch-project/security#1687 and now is seeing a jar hell conflict. This will fix that conflict and fix the CVE in this version of OpenSearch

Caused by: java.lang.IllegalStateException: jar hell!
class: com.fasterxml.jackson.dataformat.cbor.CBORConstants
jar1: /opensearch/plugins/.installing-15168128924324[135](https://github.com/peternied/security/runs/5634491143?check_suite_focus=true#step:11:135)285/jackson-dataformat-cbor-2.13.2.jar
jar2: /opensearch/lib/jackson-dataformat-cbor-2.12.6.jar
	at org.opensearch.bootstrap.JarHell.checkClass(JarHell.java:317)
	at org.opensearch.bootstrap.JarHell.checkJarHell(JarHell.java:212)
	at org.opensearch.plugins.PluginsService.checkBundleJarHell(PluginsService.java:676)
	... 11 more

Check List

• New functionality includes testing.
  • All tests pass
• New functionality has been documented.
  • New functionality has javadoc added
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[opensearch-ci-bot]

✅   Gradle Check success 8529ee3
Log 3634

Reports 3634

[nknize]

LGTM!

[peternied]

@saratvemulapalli Could we get this change backported to 1.4?

[cliu123]

@saratvemulapalli Could we get this change backported to 1.4?

+1
@saratvemulapalli @nknize @dblock Should this be backported to 1.x branch for 1.4? Security plugin has already backported it to 1.x branch. If it doesn't make sense for OpenSearch core to do the same, security plugin would need to revert the backport.

[dblock]

I don't see why we wouldn't backport to 1.x, labeled.

[cliu123]

@dblock makes sense. Then should we also backport it to 1.3, 1.2, 1.1 and 1.0 branches where version has already been bumped to the potential next patch versions? Adding @saratvemulapalli @nknize for inputs.

[saratvemulapalli]

Sure absolutely. Not sure if there is going to be 1.3.1/1.4.

[cliu123]

Sure absolutely. Not sure if there is going to be 1.3.1/1.4.

Good point! But they can be different topics. If we'll have next patch release on those branches, should this CVE fix be included? If yes, then it should be backported to all the branches. This is actually a general question on how far we backport CVE fixes. Is there any agreement documented anywhere?

[saratvemulapalli]

Sure absolutely. Not sure if there is going to be 1.3.1/1.4.

Good point! But they can be different topics. If we'll have next patch release on those branches, should this CVE fix be included? If yes, then it should be backported to all the branches. This is actually a general question on how far we backport CVE fixes. Is there any agreement documented anywhere?

Usually depending on how severe the CVE is.
If it is critical, we do start a patch release for existing minor version.
If not, it will go out to the next release (could be major or minor).

[opensearch-trigger-bot]

The backport to 1.3 failed:

The process '/usr/bin/git' failed with exit code 1

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-1.3 1.3
# Navigate to the new working tree
cd .worktrees/backport-1.3
# Create a new branch
git switch --create backport/backport-2548-to-1.3
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 d43235c5cfc3f6253530bf51cb6fb4d6dd7e0154
# Push it to GitHub
git push --set-upstream origin backport/backport-2548-to-1.3
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-1.3

Then, create a pull request where the base branch is 1.3 and the compare/head branch is backport/backport-2548-to-1.3.