[
https://issues.apache.org/jira/browse/LIVY-878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17652880#comment-17652880
]
Larry McCay commented on LIVY-878:
----------------------------------
[~ksumit] - thanks for the details. The way that I read this, it seems that we
have a couple possible directions:
# [~dacort]'s current direction which would help move Livy along upstream from
internal versions and be on an official API bridge for log4j 2. This will
necessarily tease out all of the transient dependencies where they will need to
be excluded.
# Another alternative would be to take the short term approach that others
have done internally for the 0.8.0 release as a stop gap for this initial
release with the rebooted community. It would require teasing out all of the
same transient dependencies of log4j to be excluded.
[~dacort] - would the API bridge require any actual code changes? If so, simply
excluding transient versions that are pulled in by other dependencies may not
be sufficient?
Personally, I would like to see an approach that moves the upstream project
farther along rather than just catch up with forks. This would however require
little to no heavy lifting in order for this to be picked up by downstream
consumers. Otherwise, it would be introducing risk.
It seems like we can probably continue down the API bridge path since it will
require the same exclusions. If it turns out that we need to change it to
reload4j then it should only require changing the poms to a different package
and the exclusions should remain the same. Right?
> Log4j upgrade for Livy 0.7.0 version
> -------------------------------------
>
> Key: LIVY-878
> URL: https://issues.apache.org/jira/browse/LIVY-878
> Project: Livy
> Issue Type: Sub-task
> Reporter: Tinu Jose
> Assignee: Damon Cortesi
> Priority: Major
> Fix For: 0.8.0
>
>
> We are looking for an advise from you in context of the below mentioned issue:
>
> *A high severity vulnerability (CVE-2021-44228) impacting multiple versions
> of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub
> on December 9, 2021.*
> *The vulnerability impacts Apache Log4j 2 versions 2.0 to 2.14.1.*
>
> Apache Livy version 0.7.0 version is being used by our team for processing
> the spark jobs . It uses the Log4j 1.x.x. which is not having any continued
> support.
> We would like to upgrade the Log4j versions to the latest stable version
> 2.15 without having any impact on the installations .
>
> Could you please recommend the possible ways to do the upgrade .Please note ,
> we are not looking to upgrade the Livy version to 0.7.1 to resolve this issue
> .
> Our requirement is to retain the current installed version and configurations
> with only changes in the Log4j versions
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
