Hi. Might be related to the patch plugin while building the distribution archives.
Adding the commons lib to the skip list in https://github.com/apache/tomee/blob/320f9a20c51a5a058e21d1f20205110d02bf6a94/tomee/apache-tomee/pom.xml#L566 might resolve it (didn't test, just a blind guess). It might also be a thing for the patch plugin itself, ie. don't tamper with the jars, if they aren't patched. As usual: PRs welcome. Gruß Richard Am 27. September 2023 14:27:03 MESZ schrieb COURTAULT Francois <francois.courta...@thalesgroup.com.INVALID>: >THALES GROUP LIMITED DISTRIBUTION to email recipients > >Hello everyone, > >Quite recently I run NexusIQ on TomEE Plus 8.0.15. >The tool reports a vulnerability on commons-collections--3.2.1. >Issue: in TomEE delivery there is no commons-collections--3.2.1 ☹ > >So we opened a ticket to NexusIQ support. >You have to know that the tools uses Maven Central for its processing. >If I download the commons-collections--3.2.2.jar from this repo and I run a >sha1 on it, I get 8ad72fe39fa8c91eaaf12aadb21e0c3661fe26d5 >Now, if I take the one inside TomEE and run a sha1 on it, I get >bd3c432b046a303c22a1915a4c6f9217b4688ea6 > >Then I performed a binary comparison using BeyondCompare. Result: there the >same ☹ >Finally, we found the issue: the sha1 difference comes from the jar metadata. >For example, the date of the files in the jar downloaded from maven central is >2015-11-13 whereas for the one from Tomee is 2023-05-08. > >It seems that TomEE somehow repackage the libraries it is using. The side >effect is that NexusIQ generates false positive. >It’s really annoying ! > >Do you have a solution for that ? > >Best Regards. > > >
