Fix the build by updating license hashes for cvus

[epugh]

Looks like license hashes got out of date, fixing the build.

[dsmiley]

CC @chatman

[hossman]

Congratulations!

This PR enabled the success of a third-party supply chain attack against the Solr code base!

Fortunately the "attacker" in this situation appears to have been well meaning: A software dev attempting to replace the jar files of the 25.10.0 release of their software they had already published...

hossman@slate:~/lucene/solr [j21] [195917484f6] $ git rev-parse HEAD
195917484f6331da361e9a03af336b0bcbef1010
hossman@slate:~/lucene/solr [j21] [195917484f6] $ grep '.' solr/licenses/cuvs*jar*
solr/licenses/cuvs-java-25.10.0.jar.sha1:61f3a3ce565a659d296775a7b06fc20dabccee41
solr/licenses/cuvs-lucene-25.10.0.jar.sha1:b5a458458255bfdfa6688a571b5bee032428f2d4

...with "newer" jars that fixed a bug, but did NOT use a new version number...

hossman@slate:~/lucene/solr [j21] [4cd4a8e016d] $ git rev-parse HEAD
4cd4a8e016d46ba5e46bbae0726f9194bdcaae44
hossman@slate:~/lucene/solr [j21] [4cd4a8e016d] $ grep '.' solr/licenses/cuvs*jar*
solr/licenses/cuvs-java-25.10.0.jar.sha1:6c22acfbdbc7f3a4a78a2edea46124df872e9ea5
solr/licenses/cuvs-lucene-25.10.0.jar.sha1:28c49fd9f03aa25dccc75da517247c9bc46e64b8

This PR circumvented the jar checksums we have in place precisely to detect supply chain injection type situations, by accepting the change w/o question.

If the "attacker" had been more malicious, this PR would have been complicit in compromising the security of any Solr deployment that enabled the cuvs solr module in a future Solr release

---

We clearly need to be more diligent in how we handle third-party jar checksum failures.

[chatman]

Sorry, @dsmiley , I missed this thread.

...with "newer" jars that fixed a bug, but did NOT use a new version number...

Yes, that's right. cuVS-Java 25.10 is pre-release, and hence it is being served from a snapshot maven repository instead of Maven Central: https://issues.apache.org/jira/browse/SOLR-17938
I'll check on the status of the cuVS release and rectify this situation soon.

The reason we couldn't version the snapshots differently is because of a strict version checking change that was introduced recently: rapidsai/cuvs#1327. Because of this, the jar does a strict version check against the .so files and if both match (25.10.0 in this case), only then does it work.

A software dev attempting to replace the jar files of the 25.10.0 release of their software they had already published...

https://github.com/apache/solr/blob/main/gradle/globals.gradle#L31, FYI. This is a snapshots repository, not a releases repository. It is possible to republish the same artifacts in snapshots repository, if absolutely needed. This is not possible for maven central releases.

[chatman]

If the "attacker" had been more malicious

Lets not assume any malice if there's an argument that can be explained by stupidity. The stupidity here is in the way the pre-release snapshots have been managed, and I take full responsiblity for this.

[chatman]

This PR enabled the success of a third-party supply chain attack against the Solr code base!

Haha.. :-D These artifacts wouldn't have made it into the hands of the users, due to the release blocker https://issues.apache.org/jira/browse/SOLR-17938. Lets silence the false alarm, please.

[chatman]

this PR would have been complicit in compromising the security of any Solr deployment

Maybe we should flag a warning via GH actions for any PR that introduces a non Maven Central artifacts repository? This way, the committers who review contributions would be notified before they merge the PRs. To be clear, in this case, I was the committer who merged the PR (#3615) with the third-party Maven repository with the full knowledge [0] of why and what is going on, so this particular instance is not an attack. FYI @narangvivek10.

[0] - #3615 (comment)

[dsmiley]

BTW @epugh , next time you do this, definitely at-mention who added the sha1 first before just merging, and also your commit should reference the appropriate JIRA (same as the one adding is fine; it's unreleased).

[aruggero]

Hi,
I am locally doing a gradlew check on the main branch, and I am facing this error:
`Execution failed for task ':solr:modules:cuvs:validateJarChecksums'.

Dependency checksum validation failed:
- Dependency checksum mismatch ('com.nvidia.cuvs:cuvs-java:25.10.0'), expected it to be: 6c22acfbdbc7f3a4a78a2edea46124df872e9ea5, but was: 885ad074984741128c7cc723851e790711f91a6e
`

I searched the Maven Central repository and I found:
https://central.sonatype.com/artifact/com.nvidia.cuvs/cuvs-java/25.10.0/versions
Released 4 days ago.
If I have a look at the sha1 from here:
https://repo1.maven.org/maven2/com/nvidia/cuvs/cuvs-java/25.10.0/
Then
https://repo1.maven.org/maven2/com/nvidia/cuvs/cuvs-java/25.10.0/cuvs-java-25.10.0.jar.sha1

I see the sha1 of the error: 885ad...
Should the one in Solr be updated? How should I fix this error?

Thank you

[chatman]

@aruggero Yes, cuvs-java was released recently. I'm tracking this in https://issues.apache.org/jira/browse/SOLR-17938.
Planning to raise a PR soon.

In order to proceed, you can try "./gradlew --refresh-dependencies".

[aruggero]

HI @chatman,
Thanks for answering.
Should the refresh resolve the issue? Or do I need to wait for the PR to be opened and then merged?

@aruggero Yes, cuvs-java was released recently. I'm tracking this in https://issues.apache.org/jira/browse/SOLR-17938. Planning to raise a PR soon.

In order to proceed, you can try "./gradlew --refresh-dependencies".