A severe security vulnerability was found for log4j2 <= 2.14.1 (see https://nvd.nist.gov/vuln/detail/CVE-2021-44228). How can I update the pom.xml of a Spring Boot application to make sure that all (recursive) usages of log4j2 use version 2.15.0?
Updates:
2022/01/04:
Log4J 2.17.1 contains a fix for CVE-2021-44832
2021/12/22:
Spring Boot 2.5.8 and 2.6.2 haven been released and provide dependency management for logback 1.2.9 and Log4J 2.17.0.
2.17.0 fixes CVE-2021-45105
2.12.2 released (2021/12/14)
2.16.0 fixes also CVE-2021-45046
OP:
spring-boot "by default" is NOT AFFECTED by CVE-2021-44228(log4shell).
Though versions [2 - 2.6.1] (any -starter) depend on log4j-api and slf4j-to-log4j,
Slf4j says:
If you are using log4j-over-slf4j.jar in conjunction with the SLF4J API, you are safe unless the underlying implementation is log4j 2.x.
To be sure,
in maven inspect the output of:
mvn dependency:tree -Dincludes='*log4j*'
in gradle:
gradle -q dependencyInsight --dependency log4j
Having spring-boot-starter-log4j2 on board
We are definitely affected (with spring-boot > 1)!
To (fix via) update, the easiest is probably:
maven:
<properties>
...
<log4j2.version>2.17.1</log4j2.version><!-- as of 2021/12/28 -->
</properties>
..in the pom.
gradle:
ext['log4j2.version'] = '2.17.1'
.. in build.gradle, or:
log4j2.version=2.17.1
.. in gradle.properties.
...build, test, release, deploy.
Links:
log4j2-vulnerability-and-spring-boot
slf4j-log4shell
CVE-2021-44228
CVE-2021-45046
CVE-2021-45105
Now it's recommended to use
<log4j2.version>2.16.0</log4j2.version>
This will also stipulate spring-boot-starter-log4j2's log4j2 components version.
<dependencyManagement>
<dependencies>
...
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j</artifactId>
<version>2.17.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
...
</dependencies>
</dependencyManagement>
Following up #Piotr P. Karwasz's recommendation, that's a better setting choice.
Update:
<dependencyManagement>
<dependencies>
...
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-bom</artifactId>
<version>2.17.0</version>
<type>pom</type>
<scope>import</scope>
</dependency>
...
</dependencies>
</dependencyManagement>
By the way, If the project's log4j dependencies are only from spring-boot-starter-log4j2, it has a definitive setting way, refer to spring blog
<properties>
<log4j2.version>2.17.0</log4j2.version>
</properties>
Generally for maven projects, you can force log4j-core version with deps mgmt.
<dependencyManagement>
<dependencies>
...
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-core</artifactId>
<version>2.17.0</version>
</dependency>
...
</dependencies>
</dependencyManagement>
After this, make sure this pom.xml and all inheriting pom.xml do define log4j deps without tag so that they will all benefit from this centralized change.
As per the apache site, the the minimum acceptable level for log4j is now 2.17.1 - The mitigation is to upgrade to Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later).
Related
I am trying to use the spring-cloud-task-core version 2.4.1 with the spring-boot version 2.6.6 (from the 2021.0.x release train).
This is showing me the below error:
Your project setup is incompatible with our requirements due to following reasons:
- Spring Boot [2.6.6] is not compatible with this Spring Cloud release train
Action:
Consider applying the following actions:
- Change Spring Boot version to one of the following versions [2.4.x, 2.5.x] .
You can find the latest Spring Boot versions here [https://spring.io/projects/spring-boot#learn].
If you want to learn more about the Spring Cloud Release train compatibility, you can visit this page [https://spring.io/projects/spring-cloud#overview] and check the [Release Trains] section.
If you want to disable this check, just set the property [spring.cloud.compatibility-verifier.enabled=false]
Does it mean that the cloud-task 2.4.1 is incompatible with spring-boot 2.6.6? Wanted to confirm here first before I raise the issue with the spring community.
Edit-1:
My Pom.xml for using spring-cloud-task-dependencies as BOM:
For previous spring-boot 2.1.1:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<version>${spring-boot.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
For proposed spring-boot 2.6.6 or 2.5.12:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-task-dependencies</artifactId>
<version>${spring-cloud-task-dependencies.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Here, I have to use the spring-cloud-task-dependencies.version because the spring-boot.version gives below error:
Spring Boot 2.6.6 and Spring Cloud Task 2.4.1 are compatible.
The message is generated by the SpringBootVersionVerifier that is part of spring-cloud-commons. You seem to have that artifact with version 3.0.x on your classpath although you need version 3.1.x.
You need to ensure that the version of spring-cloud-commons is not somehow fixed to some old version. It's easiest to have the version managed by the bom of the Spring Cloud release train 2021.0.x.
The maven snippet from the Spring Initializr for this is
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
where spring-cloud.version should be set to 2021.0.1.
I am using below Red Hat Fuse BOM for my camel application to get the camel dependencies for my project. It returns camel dependencies version 2.23.x
<dependencyManagement>
<dependency>
<groupId>org.jboss.redhat-fuse</groupId>
<artifactId>fuse-springboot-bom</artifactId>
<version>7.7.0.fuse-sb2-770010-redhat-00001</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependencyManagement>
My Maven is set to get the dependency through JFrog, which blocks camel-spring-2.23.x version due to some vulnerability found in this version of jar as per our client security policy. My question is, Will it be correct to specify the camel-spring dependency in pom.xml as below to download 2.25.x version and let the other camel lib dependencies as 2.23.x ? Is it going to cause any issue in amy camel application due to different camel library versions?
<dependency>
<groupId>org.apache.camel</groupId>
<artifactId>camel-spring</artifactId>
<version>2.25.2</version>
</dependency>
Which is the best way to determine the versions for my Spring modules and other libraries in a Spring Boot project?
Versions for Spring Modules
Versions for Third Party libraries
There are a lot of question when you search for "Compatible versions in Spring".
But all these questions are regarding specific libraries.
I would like to have general rules of how to determine compatible versions for my project.
You may checkout my post on this A comprehensive list of dependencies managed by latest Spring-Boot 2.3.2.RELEASE (as a custom parent)
That's is just a reference for how it should be, but you may discard the version in as they will be managed indirectly by spring itself.
Ok so, this is something almost every spring developer stumble upon. Let me try to explain this how was I able to resolve all the managed and third party libraries.
Let's suppose you want to build spring-boot microservices with a centralized configuration server.
So we can take it as following modules:
A company project starter: acts as a parent, managing the dependency
A config-server
A config-client
and let's suppose you chose spring-boot 2.3.2 version, which I used and find more stable. You would expect all the managed ones are using this spring-boot 2.3.2 version directly or indirectly.
I would highly recommend using https://mvnrepository.com
artifact: my_company-boot-starter-parent
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.2.RELEASE</version>
</parent>
<groupId>com.my_company</groupId>
<artifactId>my_company-boot-starter-parent</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>pom</packaging>
<name>my_company starter-parent</name>
<dependencyManagement>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<!-- ... -->
<!-- ... -->
<!-- other dependencies -->
<!-- ... -->
<!-- ... -->
</dependencyManagement>
If you got to Spring Boot Starter Parent » 2.3.2.RELEASE, under Managed Dependencies you can see the comprehensive list of all the dependencies with default version that would be referenced implicitly with boot version 2.3.2, see column Version.
The Updates column indicate that these managed dependencies are having their newest updates as this, but you are not required to override the dependency version of managed ones. If you intent to use more recent version, you have to chose more recent version of spring-boot-starter-parent. So let the spring download all the managed one itself.
With spring-boot-starter-parent 2.3.2 , they do not mention which spring-cloud-dependencies verion you should use, and this is where we get stuck and we need to figure it out.
Let us got to spring-cloud-dependencies . Hee you can see numerous version but which one to chose, it's like verifying which latest version uses spring-boot 2.3.2 indirectly.
You need to follow the managed dependency and go along with it until you find your parent version.
For example If you go for :
Hoxton.SR6
Spring Cloud Dependencies(Hoxton.SR6) -> Spring Cloud Config Dependencies( 2.2.3.RELEASE) -> Spring Cloud Starter Config(2.2.3.RELEASE) -> Spring Cloud Starter(2.2.3.RELEASE) -> Spring Boot Starter(2.3.0.RELEASE)
Here you can see, we end up using Spring Boot Starter(2.3.0.RELEASE) which is not what we expected it to be.
Hoxton.SR7
Spring Cloud Dependencies(Hoxton.SR7) -> Spring Cloud Config Dependencies(2.2.4.RELEASE) -> Spring Cloud Starter Config(2.2.4.RELEASE) -> Spring Cloud Starter(2.2.4.RELEASE) -> Spring Boot Starter(2.3.2.RELEASE)
Here we end up using same boot version 2.3.2. So in your parent pom.xml, you can set the spring cloud version as :
<properties>
<java.version>15</java.version>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
<lombok.version>1.18.20</lombok.version>
<spring-cloud.version>Hoxton.SR7</spring-cloud.version>
</properties>
And in child poms (jars), you can just use the dependencies justby mentioning the group and artifact, skipping the version.
sample:
<parent>
<groupId>com.my_company</groupId>
<artifactId>my_company-boot-starter-parent</artifactId>
<version>1.0-SNAPSHOT</version>
</parent>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<optional>true</optional>
</dependency>
<dependency>
<groupId>io.springfox</groupId>
<artifactId>springfox-boot-starter</artifactId>
</dependency>
<dependency>
<groupId>com.google.code.gson</groupId>
<artifactId>gson</artifactId>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
</dependency>
<dependency>
<groupId>com.google.googlejavaformat</groupId>
<artifactId>google-java-format</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-configuration-processor</artifactId>
</dependency>
</dependencies>
See, we have not provided the any version here, so spring-cloud-config-server version would be auto managed and it would be 2.2.4.RELEASE which again uses spring-boot-starter-web and spring-boot-starter both of 2.3.2 version.
Third party libraries
This is somewhat based on language version. You might want to use the latest third-party libs which is most recent till your language version supports it.
Like lombok: 1.18.20
Hope this might have helped you and others and provides an approach towards version compatibility.
Tips: Never forget to check the Managed Dependency Coordinates in Aappendix of all the spring boot release page as they keep their managed dependencies & version there. Like this one Appendix F: Dependency versions
1. Use Spring Initializr
Select all Spring modules you need in spring initializr and generate your code: https://start.spring.io/
You do not need to use the full generated code. But you should copy the library versions out of the generated pom.xml.
2. Watch out for dependency pom.xml
If available, import dependency pom.xml in your dependencyManagement.
Use the versions provided by these dependency poms.
E.g.
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Spring Dependency Version Documentation
You can also check the Spring Dependency Version Documentation. But I prefer the initilizr, because it's easier to handle.
The Spring documentation Using Spring Boot without the parent POM shows that the dependency on spring-boot-dependencies is added to the dependencyManagement section. Is this really correct?
spring-boot-dependencies specifies version properties for all the dependencies. However, these properties are not available in the POM that uses spring-boot-dependencies. Presumably, this is because spring-boot-dependencies is in dependencyManagement.
spring-boot-dependencies only includes dependencyManagement and pluginManagement. So it seems possible to include spring-boot-dependencies as a dependency (not dependencyManagement) without adding unnecessary dependencies.
So why is spring-boot-dependencies to be included as dependencyManagement?
So why is spring-boot-dependencies to be included as dependencyManagement?
Let's say you have a project named projectA and you add the spring-boot-dependencies to the dependencyManagement section in your pom.xml.
<project>
<groupId>com.iovation.service</groupId>
<artifactId>projectA</artifactId>
<version>1.0.0-SNAPSHOT</version>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-dependencies</artifactId>
<type>pom</type>
<version>1.5.8.RELEASE</version>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
<dependencies>
<!-- Spring Boot Dependencies -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
...
</project>
If you notice closely, you will find that all the Spring Boot dependencies declared under the dependencies section don't need to specify the version. It derives the version from the version of spring-boot-dependencies specified in the dependencyManagement section.
Advantages of Dependency Management
It centralizes dependency information by specifying the Spring Boot version at one place. It really helps during upgrade from one version to another.
Subsequent declaration of Spring Boot dependencies just mentions the library name without any version. Especially helpful in multi-module projects
It avoids mismatch of different versions of spring boot libraries in a project.
No Conflicts.
It's definitely correct. Please see Using Spring Boot without the parent POM!
First, let’s understand what dependency is. So when you are developing an application, you would probably need a number of libraries(normally jar files). It means that your application depends on these libraries. Hence the name dependency.
Now you need a way to assemble all these libraries and manage them in a centralized fashion. This also means that these libraries would be made available at compile time or runtime when needed. This is what dependency management does.
So the process of dependency management involves locating these dependencies and adding them to the classpath.
Maven is a popular dependency management tool which will centralize all dependencies information.
I have done considerable research in internet and I haven't found any easy explanation what to do with BOM files with Maven.
The problem is that I use JBoss 7.1.1 and I want to include all JBoss client jars in pom.xml. JBoss has a manual that says that I should use BOM files, but I don't know how to use it in my pom.xml.
Please help.
A bom is a so called bill of materials - it bundles several dependencies to assure that the versions will work together. JBoss has boms for many of it's projects, including Arquillian and the JBoss AS itself.
There is an explanation of the bom usage in the maven docs - it is hidden well below.
A practical example:
You include the bom into your pom like this:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jboss.bom</groupId>
<artifactId>jboss-javaee-6.0-with-tools</artifactId>
<version>${javaee6.with.tools.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Then you do not have to specify the version attribute of a dependency, if it is defined in the bom like this:
<dependency>
<groupId>javax.enterprise</groupId>
<artifactId>cdi-api</artifactId>
<scope>provided</scope>
</dependency>