I've refreshed the Google doc with some more data comparing solr:10.0.0, solr:9.8.1, solr:9.10.1, to our current unreleased Solrs, and the situation is much much improved in the under development Solrs.
https://docs.google.com/document/d/1c_qRBfNS6To4I9AUti_7mGGADPaFmAZVomKGoDK7LRg/edit?tab=t.0#heading=h.scm8h0fzyr6a On 2026/08/06 14:22:40 Eric Pugh wrote: > Yesterday I published the new OpenVEX support to our > https://solr.apache.org/security-dependency-cves.html site. OpenVEX is used > by "docker scout" command, a common CVE analysis tool from Docker. > > I wanted to measure progress, so I compared our released Solr 9 and 10's to > unreleased versions, plus layered in what the VEX statement say about CVE's > actually being exploitable or not. > > https://docs.google.com/document/d/1fbYFhve8eYYkgzYLiHcHIqsPFX4zvJTApC_4wm-uQVo/edit?usp=sharing > > At this point, I think the bulk of the "tooling" work is done, and now we > need to just continue to use it. I'm going to look at expanding VEX coverage > over the remaining CRITICAL and HIGH ones. > > I'd love to present this data at the next communtiy meetup ;-) > > Eric > > On 2026/07/18 15:54:56 David Smiley wrote: > > After reviewing your PRs and doing my own investigation... I see that > > search.maven.org is less useful than I hoped. It didn't fully resolve the > > transitive graph, even though through the UX I asked it for transitives. > > In particular, for solr-opentelemetry, it could only traverse as far as > > grpc-netty without seeing the specific netty dependencies you were speaking > > of and that which we indeed ship in releases. So I'll continue to use it > > knowing that it isn't comprehensive. That's not good enough for the VEX > > analysis you are doing. > > > > BTW when I spoke of Solr's TGZ, it extends to Solr's docker image as well. > > Both are authoritative releases. > > > > On Sat, Jul 18, 2026 at 10:51 AM David Smiley <[email protected]> wrote: > > > > > On Sat, Jul 18, 2026 at 9:21 AM Eric Pugh <[email protected]> wrote: > > > > > >> In PR 204 you will of course see how I am struggling to figure out how to > > >> map specific jars to specific versions of Solr... If anyone has some > > >> good > > >> ideas, I'm all ears. It's currently a working, but also way to brittle, > > >> approach. > > > > > > > > > Do you mean, which Solr versions included a specific dependency version? > > > I didn't see that in the PR but I'm not a python coder. > > > > > > The info is in pom.xml but it's a fraught path, I think, to go that > > > way. You could interroagate Sonatype's API: > > > https://central.sonatype.org/search/rest-api-guide/ -- search.maven.org. > > > It seems to be powered by Solr, BTW. That site is where *I* go to get > > > quick answers to wondering what dependencies does Solr have at a specific > > > version -- or any Java/JAR artifact out there. I use solr-core typically > > > but if it relates to a module, I lookup the module. This approach will > > > not > > > work for a small minority of JARs in Solr's TGZ... like some logging or > > > maybe Jetty level JARs which conceptually is underneath Solr. In that > > > respect, perhaps the most comprehensive solution involves a JAR scanner of > > > each distribution. Basically all JARs self-identify in META-INF inside. > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
