The issue cropped up when cuvs-java was released and was available via maven central while an unofficial maven repo also had the same artifacts (with different checksums). I've removed the artifacts from the unofficial repo and running precommit. Will confirm once this is resolved.
Broader question is how do we work with pre-release software which is not available on Maven Central yet, but will soon be. If the answer to that is that we never attempt to integrate anything *before* they are released, then that is also fine. Though, it feels limiting, if we're trying to stay cutting edge. On Sat, 1 Nov 2025 at 01:53, Anshum Gupta <[email protected]> wrote: > +1 Hoss and thanks for framing that as well as you did. > > On Fri, Oct 31, 2025 at 12:18 PM Chris Hostetter <[email protected] > > > wrote: > > > > > IMO... > > > > Any discusion of a "Workaround" for checksum missmatches is intrinsically > > a discussion of intentionally weaking the (very minimal) security we put > > in place to ensure that people who run our code are using the same > > third-party "bits" that we (as developers) have also run. > > > > (We may not have any confidence that those third-party "bits" aren't > > malicious, but at least we know we're all using the same bits) > > > > > > IMO... > > > > Any discussion of intentionally weaking that (very minimal) security > > should be a non-starter. > > > > The only discussions we should be having around checks related to our > > third-party jars should be about *increasing* security (applying the > > checksum validation before letting gradle load those jars to run tests, > > doing security scans of new versions before upgrading, etc...) > > > > > > IMO... > > > > modules/cuvs should be completely ripped out of all Solr branches until > > such time as: > > > > * cuvs related deps w/Completley *new* versions (or names) are "released" > > * All cuvs related deps are released to trusted maven repos (SOLR-17938) > > > > ...if that means Solr 10 ges released w/o cuvs -- so be it. > > > > > > -Hoss > > http://www.lucidworks.com/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > Anshum Gupta >
