For org.apache.servicemix.bundles:org.apache.servicemix.bundles.commons-collections it appears that there are three versions on maven
https://central.sonatype.com/artifact/org.apache.servicemix.bundles/org.apache.servicemix.bundles.commons-collections/3.2.1_3/versions
All of which look to have a copy of the commons collections to me.

Thanks @darakian, I'll look into those other versions today and try to flesh this PR out a bit more 👍

Hi @darakian,

You were right -- those 2 versions of org.apache.servicemix.bundles:org.apache.servicemix.bundles.commons-collections are also vulnerable. Thank you for spotting that! They weren't picked up automatically by our tool because their source code jars were missing from Maven Central Repo. I've added pom.xmls to repro these vulnerabilities in the xshady-release repo, and added extra versions in fb36249. Gory details in jensdietrich/shadedetector#78.

In 6fd3b9e I've also added some more source repo metadata, and a reference to the paper preprint.

Is this PR now good to go do you think?

Hi @darakian,

To get past the "Explicitly listing more than one affected version is not currently supported. Use range events instead" error, 5c57656 removes the complete list of explicit versions -- this seems less misleading than leaving any one of the 3 there.

It would be great if we could somehow specify explicitly that we know these 3 versions are definitely vulnerable, because I think merging the PR in its current state will only make the GHSA suggest this, based on:

• these 3 versions exist at the time of this GHSA update
• I didn't include a fixed or last_affected entry
• the assumption that I would have tested all versions available at the time of the GHSA update

Is there a way to explicitly specify this? I didn't see anything that does exactly this at https://ossf.github.io/osv-schema/. I could just add "last_affected": "3.2.1_3", but https://ossf.github.io/osv-schema/#last_affected-vs-fixed-example says

The last_affected field is typically assigned at the time of discovery and assumes the vulnerability will be addressed in the following version.

but I don't know if that assumption is reasonable.

Otherwise I think this PR is ready?

Gah, sorry for the delay again. I think this looks good as well. For the future if you want to add a list of single versions then you need to add a new affected product for each. Given the range you removed I could manually add back >= 3.2.1_1, <= 3.2.1_3.

Given the range you removed I could manually add back >= 3.2.1_1, <= 3.2.1_3

Please do! (For reference is that something I could have done myself in this PR, by making new affected products for each single version as you suggested in the previous sentence? Or something only you can do?)

Thanks @darakian!

Hi @wtwhite! Thank you so much for contributing to the GitHub Advisory Database. This database is free, open, and accessible to all, and it's people like you who make it great. Thanks for choosing to help others. We hope you send in more contributions in the future!

For reference is that something I could have done myself in this PR, by making new affected products for each single version as you suggested in the previous sentence? Or something only you can do?

It is, though I can also change it and as I'm trying I'm now remembering that our version logic can't handle underscores 🤦.
I went ahead and bounded the versions you specified though. Let me know if you disagree and we can edit them 👍

Thanks @darakian, the version ranges for org.apache.servicemix.bundles:org.apache.servicemix.bundles.collections-generic and org.apache.servicemix.bundles:org.apache.servicemix.bundles.commons-collections look good to me given the underscore restrictions, but I noticed a couple of other issues on the published advisory page:

• None of the new references (e.g., https://github.com/jensdietrich/xshady-release/tree/main/CVE-2015-7501) appear
• net.sourceforge.collections:collections-generic has both "= 4.0.1" and "= 4.01" listed -- the former should not be there

Welp, that's a fat finger on my end 🤦
I culled the https://svn.apache.org/... links since those can be inferred from the package and version info, but otherwise hopefully good 👍

Looks good now, thanks!