Hi Vladimir, On 30.10.2025 12:56, Vladimir Sitnikov wrote: > 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 why we are trying to automate the process. In most Java artifacts, `ClassUtils.getClass` is never called and this verdict can be delivered automatically. > 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. I totally agree. A VEX statement is not a *permanent* solution and usually you can easily upgrade to a non vulnerable version of the library in the next release. If you can't, you can run the workflow again. Note that you thread [1] on using the upper bound of the declared dependency versions instead of the first declared is pretty much required to prevent regressions. > 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. Apache Solr is bigger (371 MiB), which is why I am trying to prove that VEX generation for OSS projects this size is feasible with some automation. Your remark about duplicate effort is spot on: Google proposed the concept of “intermediate VEX-es” some time ago [2] that would allow downstream project to profit from VEX-es produced by upstream projects (like Commons). Of course for this to work dependency trees must be sanitized to: - List all JARs directly referenced in code as *direct* dependencies. As projects get larger, developers might reference some *transitive* dependencies in code, especially in Maven, where the `compile` scope is always transitive. - Some caller-callee dependencies are not expressed in the dependency tree, e.g. if `ServiceLoader` is used. >> 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. I see your point, maybe there is sense in extracting *parts* of `StringUtils` in a separate artifact. I completely understand and support your decision to migrate away from Commons Lang. I also think the Commons project *should* provide tools and guidance to help users migrate away from *some* outdated or deprecated usages, even if that means a smaller user base. - In new code that uses nullability annotations, I prefer `String.isBlank()` over `StringUtils.isBlank()`. - I disagree with adding `commons-lang3` as a dependency of `commons-compress` just to “reuse” four methods (see my PR [3]). - I believe Commons FileUpload has largely been superseded by Servlet API 3.0 and should have its feature set significantly reduced [4]. > 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. Yes, the decision to shade should not be taken lightly, since influences vulnerability management: you can no longer ignore user questions about the exploitability of a CVE, if you ship parts of the vulnerable library. Piotr [1] https://lists.apache.org/thread/8o67zmfjyjv9k44tnqooh1cbfzt3xf8o [2] https://osv.dev/blog/posts/automating-and-scaling-vex-generation/ [3] https://github.com/apache/commons-compress/pull/607 [4] https://lists.apache.org/thread/b2hkt7qdsq80qnxft5zjq0orql34ckvp --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
