Hi Chris, On 31.10.2025 20:17, Chris Hostetter wrote: > 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...)
I completely agree and I’ve been made some initial work under SOLR-17657 (Gradle Verification Metadata) [1]. The current PR #3828 draft [2] doesn’t yet increase security per se (Trust-on-First-Use SHA-256 checksums are equivalent in strength to the current SHA-1 approach) and it doesn’t solve the cuVS issue either (for that, Gradle would need to use full PURLs including the `repository_url`). However, it does establish a foundation that can be built upon. One possible next step would be to introduce PGP signature verification. Even with Trust-on-First-Use keys, Gradle could detect a change in a dependency’s signing key and fail the build, prompting review. Later, these keys could be replaced with *manually verified* ones. For ASF dependencies, though, it might make sense to wait for *ATR* integration before pursuing that route. I looked at the Logging Services `KEYS` file and noted that: - It still contains small keys belonging to committers inactive for nearly 20 years. - It’s distributed from the same server as the artifacts it’s meant to verify (although this doesn’t apply when downloading from Maven Central). Other ASF committees might have similar problems. Piotr [1]: https://issues.apache.org/jira/browse/SOLR-17657 [2]: https://github.com/apache/solr/pull/3828 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
