> 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.
100% agree that it'd be irresponsible to disable this check for a release. I guess unwritten/assumed in my initial email was that this would be something extremely short term that we wouldn't take into a release cycle. In any case it looks like the problem has been solved for now: at least according to some local testing I did and a recent comment by Ishan in Slack [1]. Ishan - I see you merged the PR link you shared above has been merged. Is that a part of the fix, or can it be reverted now that you've removed the jar from SearchScale maven? Best, Jason [1] https://the-asf.slack.com/archives/CEKUCUNE9/p1761971233342189?thread_ts=1761846399.694319&cid=CEKUCUNE9 On Sun, Nov 2, 2025 at 7:47 AM Ishan Chattopadhyaya <[email protected]> wrote: > > I tried this, https://github.com/apache/solr/pull/3825 > > It passes on GHA, Crave and local, but failed on Jenkins. Looking into it > at the moment. > > On Sat, 1 Nov, 2025, 10:15 am Ishan Chattopadhyaya, < > [email protected]> wrote: > > > 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 > >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
