>easily upgrade to a non vulnerable version of the >library in the next release >Yes, the decision to shade should not be taken lightly
Piotr, you are on Commons PMC while I am not. You have much more power, so please clarify exactly the way you think Commons should handle the modularization request. Frankly, I would accept either way: a) Commons team might decide to start with commons-stringuits. Great, and I could help with that. b) Commons team might decide that "single jar or big jars is the way to go". That's fine as well. In that case I would love to see a clear message on the project webpage that would clarify how the team suggests to use the jar if only a small subset is needed (e.g. StringUtils). >I am trying to prove that >VEX generation for OSS projects this size is feasible with some automation. Can you share a **reproducible** way to generate the same VEX? If not, then it does not sound like a proof to me. In other words, could you cover your PR [1] with tests? >In most Java >artifacts, `ClassUtils.getClass` is never called and this verdict can be >delivered automatically. Please clarify how can you do so with reflection in place. Many libraries use java.lang.reflect, and it is hard to prove none of the call sites can end up calling vulnerable class. Sometimes libraries use bytecode generation in the runtime which might trigger the problematic classes as well. Any application that uses Spring might be affected by ClassUtils CVE since an attacker might inject ClassUtils to spring.xml configuration. >- In new code that uses nullability annotations, I prefer > `String.isBlank()` over `StringUtils.isBlank()`. Take Apache Tika or Apache Cassandra as an example. They use a bit of StringUtils. Do you suggest they should migrate to machine-verifiable nullability? Sure it might help, however, it would be a significant effort. It would help a lot if there was commons-stringutils which they can use before they apply nullability. >- I disagree with adding `commons-lang3` as a dependency of > `commons-compress` just to “reuse” four methods (see my PR [3]). It would be fine to reuse if the needed classes were in the respective micro-modules though. [1] https://github.com/apache/solr-site/pull/152 Vladimir
