Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Verify hashes and PGP signatures for dependencies and plugins #10443
Gradle should allow to declare the expected hashes and/or PGP signatures for dependencies and plugins.
It is important that the build should fail before any class is loaded from the "invalid" jar (or whatever) file.
There should be a way to "fail at the build finish" to simplify CI checks (CI log would list all the violations not just the very first).
Currently Gradle does not allow to enforce integrity of the downloaded/used artifacts, so build machines are susceptible to man-in-the-middle attacks.
I want to improve the level of security across Gradle-based builds.
If Gradle build allowed to declare the expected checksums and/or PGP signatures, then it would prevent man-in-the-middle attacks.
Lots of existing package managers use PGP for trust verification:
What other alternatives have you considered?
https://github.com/signalapp/gradle-witness is a Gradle plugin that verifies resolved artifacts. However it misses lots of important features like "ability to verify downloaded plugins".
I've implemented https://github.com/vlsi/vlsi-release-plugins/tree/master/plugins/checksum-dependency-plugin. It seems to work just fine. It captures resolution of plugins, and it captures resolutions of regular configurations.
However the sad thing is
PGP signature verification would be great to have.
I think that, if Gradle otherwise supports checksum verification / locking, that code should be reused to provide the checksum portion of this feature request.
No. Please avoid mentioning #5633 here as that issue treats a "completely different" use case.
Please take into account that the key point of this issue is to prevent
There are artifacts that fail to publish PGP signatures (e.g. https://gitlab.ow2.org/asm/asm/issues/317878 and #10182 ). Build script author can't use PGP for those dependencies. The only available option becomes checksums.
In other words,
You’re saying that this issue requires allowing a build to somehow specify a checksum that a dependency must match. That is the exact definition of dependency content locking.
I imagine that this issue would require locking only for the specified dependencies instead of requiring it for all dependencies in a configuration, which would possibly be an additional requirement above #5633. But, in that case, I’d make a separate issue for enabling dependency content locking on a per-dependency basis, have that depend on #5633, and have this issue depend on that new issue.
Are there any new checksum functionalities necessary for this issue that aren’t included in #5633? Besides the functionality I mentioned above…
Here's a true story that could have been prevented by use of PGP for verification: https://twitter.com/jakewharton/status/1073102730443526144, https://blog.autsoft.hu/a-confusing-dependency/
I've implemented keyserver failover, and it looks like it is important to resolve public keys in parallel.
I'd be very interested in this feature as well, and in general I think there's a lot of things that could be done in order to protect Gradle projects against malicious attacks through dependencies. Has any progress been made?
There's a few scenarios where this verification could be applied:
These requirements could be configurable for artifacts belonging to a specific group, module, optionally also version. It could also be useful to define them for specific repositories, for example so that they're not required for Maven local.
I think there's a parallel between this issue and #1369 which is interesting to consider when designing the solution to this one. On a side note, IMO having the ability to enforce signatures is much more valuable and makes the ability to specify specific repositories for dependencies practically obsolete.
I'm curious to start a discussion about how this would take form in the API.
@MartinDevi, please check the issue description:
There's a ready to use plugin, and there's probably something being developed in Gradle Core.