<!channel> v0.8.18 is live! Highlights include: •

log4j

vulnerability patch — we recommend everyone update to the latest version as soon as possible. Shoutout to @high-hospital-85984 for quickly pushing a fix teamwork • Redshift lineage • Incubating Mode integration • & more!! Check out the full write up here!

I was using ” python3 -m pip install --upgrade acryl-datahub” but it says Successfully installed acryl-datahub-0.8.17.7 not8.18 @little-megabyte-1074

0.8.18 is currently being pushed up - some troubles with the PyPi release. thanks for the patience!

Hi! Will this make it into a release that's deployed to the helm chart for datahub?

Hi folks! PyPi v0.8.18.1 release should be good to go; helm release will be coming soon (cc: @early-lamp-41924)

Helm chart change has just gone in. New charts should be available in the next 10 minutes or so.

This is amazing! I can’t wait for seeing them live. I will let you know on Monday :)

Hi @early-lamp-41924 - I upgraded Datahub to 0.8.18 through helm to fix the log4j vulnerability, but the

elasticsearch-setup-job

seems to be failing with the below - have you seen this before? I am using elasticsearch on AWS. Works fine if I revert to 0.8.17

Hey! We have a PR out for this. https://github.com/linkedin/datahub/pull/3723 We will do a quick release with this fix. For some reason, it passed in our local tests, but on some platforms it seems to happen.

Oh got it, will keep an eye on it, thanks @early-lamp-41924 for pushing these fixes promptly, it really helps super appreciated!! The alternative is for us to temporarily shut down Datahub as this vulnerability is just so bad

Got it. so I pushed the fixes to

haven't done a huge amount of testing, but seems to be working so far @early-lamp-41924

Hi Folks, Thanks for the log4j vulnerability patch. Still elastic search uses affected log4j library internally. Are we sure that the version of elastic search being used in datahub is not affected by the vulnerability?

Hi. Are you referring to the elasticsearch container?

Yes Dexter. I mean the elasticsearch container.

Thanks for the contribution! We will push this in asap

Folks, Still I’m able to see log4j 2.11 versions in the gradle dependencies graph @early-lamp-41924

+--- org.springframework.boot:spring-boot-starter-cache:2.1.4.RELEASE
 |    +--- org.springframework.boot:spring-boot-starter:2.1.4.RELEASE
 |    |    +--- org.springframework.boot:spring-boot:2.1.4.RELEASE (*)
 |    |    +--- org.springframework.boot:spring-boot-autoconfigure:2.1.4.RELEASE (*)
 |    |    +--- org.springframework.boot:spring-boot-starter-logging:2.1.4.RELEASE
 |    |    |    +--- ch.qos.logback:logback-classic:1.2.3
 |    |    |    |    +--- ch.qos.logback:logback-core:1.2.3
 |    |    |    |    \--- org.slf4j:slf4j-api:1.7.25 -> 1.7.31
 |    |    |    +--- org.apache.logging.log4j:log4j-to-slf4j:2.11.2
 |    |    |    |    +--- org.slf4j:slf4j-api:1.7.25 -> 1.7.31
 |    |    |    |    \--- org.apache.logging.log4j:log4j-api:2.11.2
 |    |    |    \--- org.slf4j:jul-to-slf4j:1.7.26
 |    |    |         \--- org.slf4j:slf4j-api:1.7.26 -> 1.7.31
 |    |    +--- javax.annotation:javax.annotation-api:1.3.2
 |    |    \--- org.springframework:spring-core:5.1.6.RELEASE -> 5.2.3.RELEASE (*)






 +--- org.elasticsearch.client:elasticsearch-rest-high-level-client:7.9.3
|    |    |    |    |    +--- org.elasticsearch:elasticsearch:7.9.3
|    |    |    |    |    |    +--- org.elasticsearch:elasticsearch-core:7.9.3
|    |    |    |    |    |    +--- org.elasticsearch:elasticsearch-secure-sm:7.9.3
|    |    |    |    |    |    +--- org.elasticsearch:elasticsearch-x-content:7.9.3
|    |    |    |    |    |    |    +--- org.elasticsearch:elasticsearch-core:7.9.3
|    |    |    |    |    |    |    +--- org.yaml:snakeyaml:1.26
|    |    |    |    |    |    |    +--- com.fasterxml.jackson.core:jackson-core:2.10.4 -> 2.12.3
|    |    |    |    |    |    |    +--- com.fasterxml.jackson.dataformat:jackson-dataformat-smile:2.10.4 (*)
|    |    |    |    |    |    |    +--- com.fasterxml.jackson.dataformat:jackson-dataformat-yaml:2.10.4 (*)
|    |    |    |    |    |    |    \--- com.fasterxml.jackson.dataformat:jackson-dataformat-cbor:2.10.4
|    |    |    |    |    |    +--- org.elasticsearch:elasticsearch-geo:7.9.3
|    |    |    |    |    |    +--- org.apache.lucene:lucene-core:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-analyzers-common:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-backward-codecs:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-grouping:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-highlighter:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-join:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-memory:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-misc:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-queries:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-queryparser:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-sandbox:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-spatial-extras:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-spatial3d:8.6.2
|    |    |    |    |    |    +--- org.apache.lucene:lucene-suggest:8.6.2
|    |    |    |    |    |    +--- org.elasticsearch:elasticsearch-cli:7.9.3
|    |    |    |    |    |    |    +--- net.sf.jopt-simple:jopt-simple:5.0.2
|    |    |    |    |    |    |    \--- org.elasticsearch:elasticsearch-core:7.9.3
|    |    |    |    |    |    +--- com.carrotsearch:hppc:0.8.1
|    |    |    |    |    |    +--- joda-time:joda-time:2.10.4
|    |    |    |    |    |    +--- com.tdunning:t-digest:3.2
|    |    |    |    |    |    +--- org.hdrhistogram:HdrHistogram:2.1.9
|    |    |    |    |    |    +--- org.apache.logging.log4j:log4j-api:2.11.1 -> 2.11.2
|    |    |    |    |    |    \--- org.elasticsearch:jna:5.5.0

Looks like Spring has released a notice about this, the log4j-api and log4j-to-slf4j jars included as dependencies with spring boot starter logging are not exploitable on their own unless overriding the default slf4j usage by including log4j core. Blog post: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

If you look at the dependency graph, spring and elastic search client both have transitive dependency to the log4j 2.11.

Right, the Spring transitive dependency is through spring-boot-starter-logging which is addressed in the blog post I linked. The dependency included is not exploitable on its own without overriding default functionality to use log4j which DataHub does not do. It would only be vulnerable if a team extends a fork to utilize log4j and includes the log4j core dependency. ElasticSearch has also put out a blog post stating that merely including the property in the above PR is enough to prevent any exploitation.

Using

constrains

doesn't change the log4j dependency introduced by sprint-boot. As recommended below, using

resolutionStrategy

gives the expected result. https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot

configurations.all {
	resolutionStrategy.eachDependency { DependencyResolveDetails details ->
		if (details.requested.group == 'org.apache.logging.log4j') {
			details.useVersion '2.15.0'
		}
	}
}