You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm using gradle to build my Java project https://github.com/marco-schmidt/am Dependabot is enabled for this project and regularly creates pull requests for new dependency versions.
In a nutshell, that feature will test all files belonging to dependencies (libraries, plug-ins) against a list of allowed hash values to make sure repositories cannot introduce malware with slightly modified versions of popular dependencies: https://github.com/marco-schmidt/am/blob/master/gradle/verification-metadata.xml
Naturally, whenever a new version of a dependency is being used, its hash value is not yet contained in that XML file. Therefore, dependabot updating a version number now always results in a failed attempt to build, making it less useful and interfering with the statistics for successful upgrades (the compatibility percentage value shown in the pull request).
In order to keep the verification feature happy, a parameter can be used to update the XML file: ./gradlew build --write-verification-metadata sha256
How can I make Dependabot use that additional argument? I don't want to use that argument all the time because I want the build to fail on developer machines (including mine) if unknown or modified file versions appear.
Or is there any other way to handle this situation?
Thanks for providing Dependabot,
Marco
The text was updated successfully, but these errors were encountered:
I'd be happy if it simply bumped the version in gradle/verification-metadata.xml just like it does in build.gradle. That way as long as it's still PGP-signed by the same publisher, the publishing key very likely won't have changed, and the build would succeed. If the publishing key does change along with the version bump, that's something I would want to see fail the build, so the maintainer knows to go hand-validate the new publishing key and version.
Today we do all our Gradle parsing in Ruby/Regex, which is brittle and doesn't easily allow supporting extra features like this.
Long term, we'd like for Dependabot to be primarily glue code that hands off to the native package managers for actual resolving. But doing that for Gradle is a larger lift, so until that happens, we won't be able to implement this.
That said, this is all open source, so if anyone is interested in submitting a PR, we'd definitely be interested.
jeffwidman
changed the title
Gradle Dependency Verification Will Always Fail with Dependabot
Add support for Gradle's Dependency Verification feature
Feb 11, 2023
I'm using gradle to build my Java project https://github.com/marco-schmidt/am Dependabot is enabled for this project and regularly creates pull requests for new dependency versions.
I recently started using gradle's new dependency verification feature: https://docs.gradle.org/current/userguide/dependency_verification.html
In a nutshell, that feature will test all files belonging to dependencies (libraries, plug-ins) against a list of allowed hash values to make sure repositories cannot introduce malware with slightly modified versions of popular dependencies: https://github.com/marco-schmidt/am/blob/master/gradle/verification-metadata.xml
Naturally, whenever a new version of a dependency is being used, its hash value is not yet contained in that XML file. Therefore, dependabot updating a version number now always results in a failed attempt to build, making it less useful and interfering with the statistics for successful upgrades (the compatibility percentage value shown in the pull request).
In order to keep the verification feature happy, a parameter can be used to update the XML file:
./gradlew build --write-verification-metadata sha256
How can I make Dependabot use that additional argument? I don't want to use that argument all the time because I want the build to fail on developer machines (including mine) if unknown or modified file versions appear.
Or is there any other way to handle this situation?
Thanks for providing Dependabot,
Marco
The text was updated successfully, but these errors were encountered: