carlosame commented on PR #2: URL: https://github.com/apache/xalan-java/pull/2#issuecomment-1194029452
Hello, I'm the maintainer of [EchoXSL](https://github.com/css4j/echoxsl), a recent fork of Apache Xalan-J. I'm happy that the Xalan Project wants to produce an additional release with a fix for CVE-2022-34169, however the way it is done in this PR would be problematic for modular JDKs. As explained in css4j/echoxsl#2, the vulnerability belongs in fact to Apache BCEL, and Xalan is vulnerable because it bundles an old version of it in the jar (together with java-cup etc). However other software do also depend on BCEL or java-cup, and in modular projects this would lead to a [split packages](https://www.logicbig.com/tutorials/core-java-tutorial/modules/split-packages.html) problem. Moreover if you just download the vulnerable BCEL jar file and add its packages, Xalan would still be vulnerable. My suggestion would be to fix the vulnerability in the BCEL project, and then set it up as a dependency in Xalan. This is the approach that EchoXSL followed and works fine. The resulting Maven POM should include something like this in the `dependencies` section: ```xml <dependency> <groupId>org.apache.bcel</groupId> <artifactId>bcel</artifactId> <version>6.5.1</version> <scope>compile</scope> </dependency> ``` Feel free to reuse the Gradle build in EchoXSL if it is of any help. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@xalan.apache.org For additional commands, e-mail: dev-h...@xalan.apache.org
