Add verification metadata update support to gradle manager

[dbast]

What would you like Renovate to be able to do?

Update gradle manager to also update the verification-metadata.xml when dependency versions get incremented.

Background: Gradle supports dependency verification to protect against supply chain attacks by maintaining a $PROJECT_ROOT/gradle/verification-metadata.xml (see also https://docs.gradle.org/current/userguide/dependency_verification.html) with the checksums MD5, SHA1, SHA-256 and/or SHA-512. Gradle fails if dependency versions get updated and the according checksum is missing. It would be very nice to also update the verification-metadata.xml on each dependency update in order to see CI checks of renovate PRs be passing without any additional manual intervention / update.

The checksums can be update via gradle --write-verification-metadata sha256 help as mentioned in https://docs.gradle.org/current/userguide/dependency_verification.html#sec:bootstrapping-verification

If you have any ideas on how this should be implemented, please tell us here.

1. Detect if the file $PROJECT_ROOT/gradle/verification-metadata.xml is present
2. Detect what type of checksums it contains MD5, SHA1, SHA-256 and/or SHA-512.
3. Call $gradle --write-verification-metadata $hash_type1,$hash_type2 help during updateDependency in https://github.com/renovatebot/renovate/blob/main/lib/manager/gradle/shallow/update.ts#L6

Is this a feature you are interested in implementing yourself?

Maybe

[rarkins]

Sounds like a good fit for our "artifacts" concept. Can you start with a reproduction repo?

[github-actions[bot]]

Hi there,

Help us by making a minimal reproduction repository.

Before we can start work on your issue we first need to know exactly what's causing the current behavior. A minimal reproduction helps us with this.

To get started, please read our guide on creating a minimal reproduction to understand what is needed.

We may close the issue if you (or someone else) have not provided a minimal reproduction within two weeks. If you need more time, or are stuck, please ask for help or more time in a comment.

Good luck,

The Renovate team

[dbast]

Created a minimal example here: https://github.com/dbast/gradle-minimal

The renovate bot opens two PRs, which are currently missing the verification metadata update, thus CI fails:

• https://github.com/dbast/gradle-minimal/pull/4
• https://github.com/dbast/gradle-minimal/pull/5

There are two other manually created PRs where each additionally contains another commit with updated verification metadata, thus CI is successful:

• https://github.com/dbast/gradle-minimal/pull/6
• https://github.com/dbast/gradle-minimal/pull/7

The intention is to update manager:gradle to also update the verification metadata.

[rarkins]

And can you confirm that running gradle --write-verification-metadata sha256 run against the failing PRs is enough? Is it common to use gradlew instead?

[viceice]

I think it should use Gradle wrapper.

[dbast]

@rarkins Yes, updating the renovate PRs by just applying ./gradlew --write-verification-metadata sha256 is enough... that is what the PRs 6+7 in the minimal example repo contain.

Regarding gradle wrapper usage: There is some logic that can be reused in https://github.com/renovatebot/renovate/blob/main/lib/manager/gradle/deep/index.ts#L39 that uses the wrapper via ./gradlew with fallback to gradle, if the wrapper is not present.

Where is the correct place to do the $gradle --write-verification-metadata sha256 call? Does it have to run as part of the existing updateDependency function or is it required to add a new updateArtifacts function to the gradle manager? I assume the later by looking into how other managers do it. Is that correct?

[rarkins]

It should be part of updateArtifacts()

[chludwig-haufe]

May I add that besides the hash sum types mentioned by @dbast, the manager needs to add pgp to the Gradle (wrapper) call if signature verification is enabled. Because otherwise, renovate would inadvertently turn signature verification off.

I would not try to automatically update any keyrings using --export-keys. Keys are not supposed to change often. If it happens, I want to convince myself that the key change is legit.

[OscarSpruit]

What is the status of this? I'm very much interested in this feature. Assuming this feature is not yet available; what is the best way to automatically update the verification metadata after Renovate updated a dependency now?

[renovate-release]

:tada: This issue has been resolved in version 36.51.0 :tada:

The release is available on:

• GitHub release
• 36.51.0

Your semantic-release bot :package::rocket: