Review/support upcoming dependency verification in Gradle 6.2

[vlsi]

Gradle 6.2 will have integrated dependency verification for integrity and provenance.

Issue: gradle/gradle#10443
Documentation PR: gradle/gradle#11755

Note: as Gradle would switch to "verify all resolutions", it would effectively prevent the operation of gradle-versions-plugin.

It looks like there will be ResolutionStrategy#disableDependencyVerification() API to temporary disable the verification.

Do you think that would be OK for G-V-P?

[ben-manes]

Thanks for the heads up. If we use Groovy's obj.metaClass.respondsTo to reflectively check for that method, it could be added in a backwards compatible fashion.

[anuraaga]

@vlsi I was looking at this now that 6.2 RC1 is released - did you mean this behavior would be automatically enabled or that a user may enable it manually and we need to account for it?

I added 6.2-rc-1 to the integration test and it passed without any code change so wondering if there's anything we actually need to do here.

https://github.com/ben-manes/gradle-versions-plugin/blob/master/src/test/groovy/com/github/benmanes/gradle/versions/DifferentGradleVersionsSpec.groovy#L118

[anuraaga]

Looking more at the docs - I guess the test case needs to have the XML file included for any behavior change. Let me see if I can trigger it

https://github.com/gradle/gradle/pull/11755/files?short_path=b4b6735#diff-b4b6735dfc9950354518beb3ed1f4117

[vlsi]

@anuraaga , it is not enabled by default.
It is activated by the presence of gradle/verification-metadata.xml file.

For instance, if you launch Gradle with --write-verification-metadata it will create a file.
Then all subsequent Gradle executions would verify the dependencies and deny the resolution of unresolved ones.

[anuraaga]

@vlsi I merged the unit test in #375 and suspect we can close this issue - please close if you think we're all done here.

[ben-manes]

I tried this with 6.2 and it fails when a verification-metadata.xml is present.

$ gradle :dU --refresh-dependencies
...
Dependency verification is an incubating feature.

FAILURE: Build failed with an exception.

* What went wrong:
A problem occurred configuring root project 'serverless'.
> Dependency verification failed for configuration ':classpath':
    - On artifact activation-1.1.jar (javax.activation:activation:1.1) in repository 'Gradle Central Plugin Repository': checksum is missing from verification metad
...
  If the artifacts are trustworthy, you will need to update the gradle/verification-metadata.xml file by following the instructions at https://docs.gradle.org/6.2/userguide/dependency_verification.html#sec:troubleshooting-verification

  These files failed verification:
    - GRADLE_USER_HOME/caches/modules-2/files-2.1/com.fasterxml.jackson.core/jackson-annotations/2.9.10/53ab2f0f92e87ea4874c8c6997335c211d81e636/jackson-annotations-2.9.10.jar
...
  GRADLE_USER_HOME = /Users/ben/.gradle

[anuraaga]

@ben-manes Can you confirm just normal gradle build works?

I can't repro in the integration test or https://github.com/anuraaga/gradle-scratch even with released 6.2 so if you can give an example would be awesome.

[ben-manes]

Yes, that fails too. See the attached project.

gradle.zip

[anuraaga]

From my understanding, it's ok for dependencyUpdates to fail if build is failing - the latter failing means the project is currently broken anyways (it needs the verification metadata updated). While I think we may be able to allow dependencyUpdates to ignore that, do you think it's worth it? This would be a possibly convenience trick, but not related to the original issue here where we suspected it effectively prevent the operation of gradle-versions-plugin, which I think meant it would fail even when the normal project build is succeeding.

[ben-manes]

Oh that’s reasonable. I didn’t think that far ahead and did not try with proper checksums in place. I don’t strongly feel one way or the other, so if we can do nothing that’s probably preferable.

[vlsi]

Frankly speaking, I expected that Gradle would deny resolution of "unknown/untrusted" metadata and artifacts. However, if it works, I'm ok with that.

I don't have much time to investigate why it is not really blocking gradle-versions-plugin :-/

[ben-manes]

Confirmed that the task passes with my sample after generating the checksum file,

gradle --write-verification-metadata sha256 help

So let's close this until it breaks on someone. When it does we'll add disableDependencyVerification() to our resolution strategy, and users can do that manually for now if needed.