[CXF-8621] cxf-rt-ws-security contains velocity:1.7 from 2010 which has overlapping classes with velocity-engine-core:2.3 and breaks velocity-tools 3.1

• Type: Task
• Status: Closed
• Priority: Major
• Resolution: Won't Fix
• Affects Version/s: 3.4.5
• Component/s: WS-* Components
• Estimated Complexity: Unknown
• Assignee: Colm O hEigeartaigh
• Reporter: Gernot Hueller
• Created: 01/Dec/21 15:53
• Updated: 18/Sep/23 18:51
• Resolved: 02/Dec/21 10:12

Description

please see this gradle dependency tree:
--- org.apache.cxf:cxf-rt-ws-security:3.4.5
     +--- org.apache.cxf:cxf-rt-security-saml:3.4.5
     |    --- org.apache.wss4j:wss4j-ws-security-dom:2.3.3
     |         +--- org.apache.wss4j:wss4j-ws-security-common:2.3.3
     |         |    +--- org.opensaml:opensaml-saml-impl:3.4.6
     |         |    |    +--- org.apache.velocity:velocity:1.7

Velocity 1.7 and 2.3 have sometimes the same class names, with different contents.
In the end, the presence of velocity:1.7 classes breaks stuff from velocity 2.3.

 

details from my case: I have an application that uses cxf for SOAP and velocity for html rendering.
In that application, I extend the VelocityViewServlet from velocity-tools, which on initialization looks at all field declarations of interface org.apache.velocity.runtime.RuntimeConstants. This interface class exists in both versions of velocity, but with different contents, which make my application unuseable (Exception on startup).

 

it would be great if the dependency to velocity inside cxf could be removed.
Especially when it is in the ws-security package and that uses a totally outdated (2010) velocity package with known vulnerabilities...

Issue Links

• is related to: WSS-683 WSS4J depends on Velocity 1.7 which contains a security vulnerability (CVE-2020-13936)
• is related to: CXF-7405 Upgrade to commons-lang3 and Velocity 2