I'm trying to upgrade the logback-classic library from version 1.2.3 to 1.2.8. The patch notes say that all DB related code has been removed, so the main DBAppender class no longer exists in the new version https://logback.qos.ch/news.html. Has anyone found some kind of upgrade guide or know of a workaround solution?
Please see https://logback.qos.ch/news.html.
2022-04-20, Release of logback.db version 1.2.11.1
As of logback version 1.2.8 DBAppender no longer ships with logback.
However, DBAppender for logback-classic is available under the
following Maven coordinates:
ch.qos.logback.db:logback-classic-db:1.2.11.1
and for logback-access under
ch.qos.logback.db:logback-access-db:1.2.11.1
Both of these artifacts require
ch.qos.logback.db:logback-core-db:1.2.11.1 which will be pulled in
automatically by Maven's transitivity rules.
I was wondering the same thing after upgrading spring to the 2.6.3 which pulls in logback version 1.2.8+ through spring-boot-starter-logging dependency.
According to logback's site: https://logback.qos.ch/news.html in version 1.2.8: "2) we have removed all database (JDBC) related code in the project with no replacement."
My logback xml configuration file has a custom DB Appender in it and the application failed to build with the following error:
Could not create an Appender of type [ch.qos.logback.classic.db.DBAppender]. ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type ch.qos.logback.classic.db.DBAppender
After doing some research, I found a ticket in the logback backlog with a request to document how to proceed. https://jira.qos.ch/browse/LOGBACK-1609
Apparently the DB appender was removed due to a vulnerability.
According to the developer: "The source code is still there. Until this issue is resolved, you can fetch the code from tag 1.2.8 and rebuild. The DBAppender issue is a bit more complex than what people think. As you can imagine, we have a lot on my plate these days but we'll get to it eventually."
So it sounds like the code was removed while they work on a fix and support will be added back eventually. I wouldn't count on a quick fix though.
As a workaround I have pinned the logback version in my projects gradle file so that I can use the latest version of spring along with the latest version of logback that still supports the DB appender class.
Here is the syntax I used:
ext['logback.version'] = '1.2.7'
Related
Apache avro scanning shows the log4j vulnerability.
How to get rid of it?
Tried with:
java -jar target/log4j-detector-latest.jar /c/workspace/sampleApp
-- github.com/mergebase/log4j-detector v2021.12.29 (by mergebase.com) analyzing paths (could take a while).
-- Note: specify the '--verbose' flag to have every file examined printed to STDERR.
C:\workspace\sampleApp\target\SampleApp\WEB-INF\lib\avro-tools-1.9.1.jar contains Log4J-1.x <= 1.2.17 OLD
I have tried to upgrade to avro-tools version 1.11.0 that too shows the same issue.
You can modify the JAR file and delete the following files that belong to log4j 1.x within the JAR file to mitigate the vulnerabilities. They are present in the folder /org/apache/log4j/net/ within the JAR:
JMSAppender.class
SocketServer.class
SocketAppender.class
SMTPAppender.class
SMTPAppender$1.class
Once deleted these classes can no longer be used by a log4j logging configuration (which is the way to trigger the vulnerabilities).
If the application does not work after the modification it needs to be migrated to use a newer log4j 2.x version: Log4j 2.3.2 (for Java 6), 2.12.4 (for Java 7), or 2.17.1 (for Java 8 and later)) - see https://logging.apache.org/log4j/2.x/
After the log4j zero-day vulnerability, we started to look if there are any more artifacts that are using either slf4J or lower versions of log4j.
Checking the mvn dependency tree we have figured that spring-security-saml2-core is using slf4j, and we tried to exclude that from the artifact. However, we are receiving the below runtime exception :
-java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at org.opensaml.DefaultBootstrap.getLogger(DefaultBootstrap.java:246)
at org.opensaml.DefaultBootstrap.initializeXMLSecurity(DefaultBootstrap.java:189)
at
If you are referring to the CVE-2021-44228 vulnerability (aka. Log4Shell) then Slf4J is not the vulnerable library so you don't have to exclude it. Only Log4j-core is affected by this particular vulnerability for versions between 2 until before 2.15.0
See https://nvd.nist.gov/vuln/detail/CVE-2021-44228
There are other known vulnerabilities at the moment (and many that are still probably waiting to be discovered), as #eray-tufay points out. The example he gives is https://cve.report/CVE-2021-4104:
Note this issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default
So, to be protected against current and future vulnerabilities:
include in your build pipeline an automatic check against new vulnerabilities, like https://owasp.org/www-project-dependency-check/
constantly upgrade your dependendencies to use the latest versions
After adding groovie-all:3.0.8 into my build.gradle, the downloaded jars are in different version as shown bellow. Each of this jars has its 3.0.8 version and I don't know why they aren't download instead.
Appreciate any help
Thanx
Since Groovy 2.5, groovy-all is just a pom which brings in the equivalent component jars, see the according release notes. This explains that you see no groovy-all.
Regarding the version numbers: spring-boot defines the grooy version, you can print it with:
ext {
// versions taken from Spring BOM
GROOVY_VERSION = dependencyManagement.importedProperties['groovy.version']
println GROOVY_VERSION
}
and I expect it is 2.5.13 which for example is included by Spring Boot Version 2.3.4. Unfortunately you didn't specify your used Spring version.
With Spring Boot you include Groovy normally just with
compile "org.codehaus.groovy:groovy-all"
without a version number since Spring Boot defines the version.
So the question is how to override the provided Spring version - alternatively you can increase the used Spring version to get a more recent Groovy version.
To override the Spring version just exclude Groovy, eg see this SO posts:
https://stackoverflow.com/a/50972674/3181392
https://stackoverflow.com/a/47355002/734687
E.g. use:
ext['groovy.version'] = '3.0.8'
To see which component included the wrong version you can execute the Gradle task "dependencies" (find it in IDEA under the help categegory). In this answer I assumed it was Spring (and I am sure it was).
I upgraded the spring-web module version from 5.1.2.RELEASE to 5.2.4.RELEASE for my Micronaut application deployed on AWS. I had to upgrade to a more stable version (suggested fix by WhiteSource) as the older version jar was considered to be highly vulnerable from a security standpoint by the WhiteSource tool.
The issue is that most of my application's endpoints worked just fine as they were mainly database queries but I noticed that if I make a REST call, the endpoint fails with the following error:
Invocation with requestId [ca31a9a5-35b3-4b52-a955-e304d9021880] failed: org.springframework.util.Assert.noNullElements(java.util.Collection, java.lang.String)java.lang.NoSuchMethodError: org.springframework.util.Assert.noNullElements(java.util.Collection, java.lang.String)
at org.springframework.web.client.HttpMessageConverterExtractor.<init>(HttpMessageConverterExtractor.java:77)
at org.springframework.web.client.RestTemplate$ResponseEntityResponseExtractor.<init>(RestTemplate.java:988)
at org.springframework.web.client.RestTemplate.responseEntityExtractor(RestTemplate.java:819)
at org.springframework.web.client.RestTemplate.exchange(RestTemplate.java:582)
at com.connector.getToken(Connector.java:58)
Downgrading the version is not much of an option as those jars will be rejected/deemed vulnerable by WhiteSource. Is there another workaround/solution for this? Please let me know! Thanks.
Make sure to upgrade the spring-core dependency to 5.2.4.RELEASE as well.
Or rather: Make sure that all spring- dependencies have the same version number.
Specifically, I use spring only for configuring my project through ApplicationContext. In my spring xml I load some bean properties through PropertyPlaceholderConfigurer. Whenever in the dependencies I swap commons-logging-x.x with jcl-slf4j.jar the loading of the context fails with ClassNotFoundExceptions on the placeholder substitutions. Example:
In my spring.xml there is:
<bean id="testbean" class="${testbean.implementingClass}"/>
where testbean.implementingClass is defined in spring.properties:
testbean.implementingClass=my.implementation.TestClass
If I run the project using commons-logging jar all works perfectly. If I change it to jcl-slf4j then I get ClassNotFoundException that the class [${testbean.implementingClass}] was not found, i.e. it does not do the placeholder substituion. Has anyone observed this?
EDIT: My problem doesnt have to do with the jars because:
From http://www.slf4j.org/legacy.html :
Our JCL over SLF4J implementation will allow you to migrate to SLF4J gradually, especially if some of the libraries your software depends on continue to use JCL for the foreseeable future. You can immediately enjoy the benefits of SLF4J's reliability and preserve backward compatibility at the same time. Just replace commons-logging.jar with jcl-over-slf4j.jar. Subsequently, the selection of the underlying logging framework will be done by SLF4J instead of JCL but without the class loader headaches plaguing JCL. The underlying logging framework can be any of the frameworks supported by SLF4J. Often times, replacing commons-logging.jar with jcl-over-slf4j.jar will immediately and permanently solve class loader issues related to commons logging.
When you use jcl-slf4j, you have to make sure you have excluded all commons-logging dependencies from your project. Make sure there is no commons-logging jar anywhere in the classpath.