VulnerableGavs.csv

[henrikplate]

Dear Andreas, all,

Great tool, thank you for taking this initiative!

I just had a quick look at VulnerableGavs.csv and noticed that groupId and artifactId are confused for some of the GAVs (e.g. io.apiman:apiman-gateway-platforms-vertx3).

Also, I wondered whether you think it is useful to add an additional column indicating whether the respective GAV declares a dependency on the original log4j-core, or whether it re-bundles the vulnerable code. The presence of a classifier may be an approximation, but does not cover all cases (e.g. org.ops4j.pax.logging:pax-logging-log4j2 re-bundles a vulnerable log4j-core version, but does not have a classifier).

Cheers, Henrik

[anddann]

Hi Henrik,

thank you for raising the issue.

I just had a quick look at VulnerableGavs.csv and noticed that groupId and artifactId are confused for some of the GAVs.

Good catch!
We'll go over it and fix ASAP.

respective GAV declares a dependency on the original log4j-core, or whether it re-bundles the vulnerable code

This is an excellent idea. I see the current version is confusing, adding this flag would make it much easier to distinguish these cases. Thanks again for the idea.

The presence of a classifier may be an approximation, but does not cover all cases.

That's a good one. Actually, we might to adapt/fix our implementation. We introduced the classifier in order to not overapproximate since we often saw the case that the jar-with-dependencies re-bundle the vulnerable code but the other versions did not.
Nevertheless, I'll take a look asap.

Thanks for your detailed issue 👍 .
Our goal is to address the issues today.

Cheers,

Andreas

[henrikplate]

Great, thank you for the prompt answer!

[henrikplate]

Hi Andreas,

Thank you for updating the CSV file. Overall, there are "just" 409 out of 18168 artifacts that rebundle vulnerable Log4j code, which is less than what I expected.

Cheers, Henrik