>Piotr: Gary and I prepared several VEX files documenting I've never heard of VEX before. However, I VEX does not solves the issue: 1) Manual review in order to prove the code is not affected is hard. I would rather drop the problematic class rather than try proving the problematic class is not reachable in the runtime. That is exactly the point I listed in "proving non-impact is often harder than bumping or excluding"
2) "proving non-impact" must happen on each subsequent release. You can't add "non_impacted" once and be done with it. Any further commit might make the code vulnerable. 3) "proving non-impact" would have to be duplicated for every consumer. For instance, I maintain Apache JMeter which ships 75 MiB worth of dependencies, see [1]. Frankly, I see no way of proving "non-impact" for the CVE at that scale. >Piotr: but I don’t think `StringUtils` fits that case. I suggested StringUtils based on the **user** experience. For instance, see [2], [3], [4]. For now I re-implemented relevant StringUtils methods in JMeter, however, the point of commons-* is unclear if everybody should drop its usage. Of course I would not mind if you extract reflection utilities to its own module, however such a module would be of no use for Apache JMeter, and Apache Cassandra. StringUtils would make an immediate difference. >Piotr: easier to *shade* by reducing unnecessary inter-class references >Gary: Maven already has a solution for projects that only want one class: Shadding. Shading helps one project; published micro-artifacts help everyone and reduce repeat work. At the same time, shading is not appropriate for the libraries: it locks users to a specific shaded version of the dependency, so the users can no longer update it. Shading makes the development and debugging harder as IDE no longer shows the proper sources for the shaded packages. Shading does not help if commons-lang is a pure transitive dependency. Frankly, I agree shading might be a useful workaround, however, it does sound strange if you suggest that shading should be the primary way of consuming commons-lang. Would you mind documenting that on the project website? >A JVM only loads a class when running code sees that reference. Maven >allows you to specify the scope of a dependency precisely. >"can" and most times not, as usual, "it depends". Gary, it looks like you miss "Mere presence of a vulnerable class on the classpath can widen attack surface" from the first email. A mere presence of a vulnerable class **is** a weakness known as CWE-1395: Dependency on Vulnerable Third-Party Component >> lang3.StringUtils could delegate all the methods to > stringutils4.StringUtils. > Gary: -1, what a horror. If delegation is not something you like, I'm fine if the initial implementation would just duplicate code. I'm fine with either way. [1] https://github.com/apache/jmeter/blob/611c21acf1b7bf447e8faa35523f77662cb6f42c/src/dist/src/dist/expected_release_jars.csv [2] https://github.com/apache/jmeter/pull/6534 [3] https://issues.apache.org/jira/browse/TIKA-4532 [4] https://github.com/apache/maven-doxia/issues/1006 Vladimir
