Security update for com.fasterxml.jackson.core:jackson-databind

It seems like the jackson-databind library has beed subject to a new security update today to correct a particular vulnerability. According to snyk at https://security.snyk.io/vuln/SNYK-JAVA-COMFASTERXMLJACKSONCORE-2421244, this vulnerability appears because of the way dependencies are being used in jackson-databind. Long story short, in order to prevent a DoS (Denial of Service) attack we only need to up grade this library to 2.13.2.1 or higher. In my case, the problem I found is that I had all libraries bound to each other like this:

<dependency>
 <groupId>com.fasterxml.jackson.core</groupId>
 <artifactId>jackson-core</artifactId>
 <version>${jackson.version}</version>
</dependency>
<dependency>
 <groupId>com.fasterxml.jackson.core</groupId>
 <artifactId>jackson-annotations</artifactId>
 <version>${jackson.version}</version>
</dependency>
<dependency>
 <groupId>com.fasterxml.jackson.core</groupId>
 <artifactId>jackson-databind</artifactId>
 <version>${jackson.version}</version>
</dependency>

Given that jackson-databind now leads off the centralized version, I had to do this:

<dependency>
 <groupId>com.fasterxml.jackson.core</groupId>
 <artifactId>jackson-core</artifactId>
 <version>${jackson.version}</version>
</dependency>
<dependency>
 <groupId>com.fasterxml.jackson.core</groupId>
 <artifactId>jackson-annotations</artifactId>
 <version>${jackson.version}</version>
</dependency>
<dependency>
 <groupId>com.fasterxml.jackson.core</groupId>
 <artifactId>jackson-databind</artifactId>
 <version>${jackson.databind.version}</version>
</dependency>

So essentially, I'm just leading the jackson-databind library off the centralised versions, by using a different variable: jackson.databind.version. Is this a pain? Well, in a way it is, but on the other hand, now I know I can control this library better. The only thing against doing this is that, depending on which dependency/security updater you are using (i.e. Snyk, Renovate, Dependabot), you will probably run into two different commits and consequentially two MR/PR's when there are version updates to this. I prefer to have two MR/PR's about this, rather than having only one and then seeing the whole project break apart and having no control over this. Case in point, this PR for my project at https://github.com/jesperancinha/sea-shell-archiver/pull/61.