HIVE-29387:upgrade commons-lang3 to 3.20.x to fix CVE-2025-48924

[ramitg254]

What changes were proposed in this pull request?

commons-lang3 upgraded to 3.20.0

Why are the changes needed?

It fixes CVE-2025-48924

Does this PR introduce any user-facing change?

No

How was this patch tested?

build locally and ci tests

[ramitg254]

dependency-tree.txt

[ayushtkn]

@ramitg254 can you check if there are other versions getting packaged as well

+- commons-lang:commons-lang:jar:2.6:compile

I think hadoop & tez are pulling in other versions

[ramitg254]

@ramitg254 can you check if there are other versions getting packaged as well

+- commons-lang:commons-lang:jar:2.6:compile

I think hadoop & tez are pulling in other versions

this pr only addresses the dependency org.apache.comcommons-lang3:jar as currently we are having the two different versions of it 3.14.0 in the pom and other one 3.17.0 which comes from hadoop which I am enforcing it to 3.20.0 in this pr

but since you mentioned the commons-lang:commons-lang:jar it can't be addressed from hive side as these are v2 versions of commons-lang having classpath of pattern org/apache/commons/lang/* which are used by underlying tez and hadoop classes and commons-lang3 have pattern like org/apache/commons/lang3/* and these v2 jars needed be brought transitively
and to change it to commons-lang3 it needed to addressed from tez and hadoop classes.
so I am only addressing the upgrade which is possible from hive side as per my understanding.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[ayushtkn]

why are you adding a dependency in scope of upgrading one?

[ramitg254]

commons-lang3 of version 3.17.0 was brought in transitively via hadoop so adding it in dependency management to ensure only newer version should be present as storage-api do not define hive pom as parent and has parent

<parent>
    <groupId>org.apache</groupId>
    <artifactId>apache</artifactId>
    <version>35</version>
  </parent>

[Aggarwal-Raghav]

@ramitg254 , I understand and totally get why these changes are made but I'm not in favour of such changes because it invites NoClassDefFoundError , NoSuchMethodError at Runtime. It's possible that commons-lang3.17 and 3.20 have API compatibility but the correct way is to wait for hadoop (as they will also have CVE) to upgrade to non-CVE version and then we can upgrade to new hadoop version.
Upgrading to 3.17.0 on other hand makes perfect sense and should be done (but it won't solve the CVE.)

I just wanted to express my concerns, I won't be in way if other PMC/committers are ok with this approach.
But my stance is -0 on this (https://hive.apache.org/community/bylaws/#voting)

[ramitg254]

@ramitg254 , I understand and totally get why these changes are made but I'm not in favour of such changes because it invites NoClassDefFoundError , NoSuchMethodError at Runtime. It's possible that commons-lang3.17 and 3.20 have API compatibility but the correct way is to wait for hadoop (as they will also have CVE) to upgrade to non-CVE version and then we can upgrade to new hadoop version. Upgrading to 3.17.0 on other hand makes perfect sense and should be done (but it won't solve the CVE.)

I just wanted to express my concerns, I won't be in way if other PMC/committers are ok with this approach. But my stance is -0 on this (https://hive.apache.org/community/bylaws/#voting)

Thanks @Aggarwal-Raghav for sharing the concern, so based on what I understood I think we can do either of two things here:

1. just upgrade that 3.14.0 version which is defined in hive pom itself in the current pr and remove that changes I added in dependency management so that no transitive dependency should be touched coming from tez and hadoop and will be fixed with those deps upgrade.

2. or I'll close this pr now and can be taken care later on when it is already been upgraded for hadoop and tez