Gradle dependency checksum and signature checks

[AndyScherzinger]

Adding checksums to Android repos like android-common for gradle based build toolchain, see https://docs.gradle.org/current/userguide/dependency_verification.html.

In order to do so, one must:

• add org.gradle.dependency.verification.console=verbose to gradle.properties so future CI runs would provide the info in case the HTML report isn't accessible
• run in the project root
  • ./gradlew --write-verification-metadata pgp,sha256 help
  • ./gradlew :sample:generateDebugLintReportModel --write-verification-metadata pgp,sha256 help
  • ./gradlew :core:spotlessKotlinCheck --write-verification-metadata pgp,sha256 help
  • ./gradlew --export-keys
  • ./gradlew :sample:generateDebugLintReportModel --export-keys
  • ./gradlew :core:spotlessKotlinCheck --export-keys
• ensure you commit verification-keyring.keys but not the binary very so git is able to diff the key changes. not executing the last command and commiting its results leads to the GH action trying to download the keys, this slows down the execution and leads to red checks since it'll fail for many keys, hence shipping them in the repo it the best option.

A next step will have to be to move to renovatebot which is capable of update checksums when updating dependencies, see https://docs.renovatebot.com/modules/manager/gradle/

---

Note

• Due to poor signature management in the library world, many libraries aren't signed or their keys aren't retrievable❗
• The above command bootstraps the whole checksum+signature information and "blindly" trusts the given key. In theory all key would need to be verified. So this setup mechanism will only secure dependency changes of the future - an already compromised dependency would not be detected/detectable this way. While keeping in mind that a legit signature isn't an absolute statement in terms of the package being legit. It just means built and published by somebody with access to the keys.

[stefan-niedermann]

Slightly Off Topic: I am currently using the gradle/wrapper-validation-action GitHub action in all of my gradle repositories (Example). It's for validating the gradle wrapper itself though, not for dependencies.

[AndyScherzinger]

@stefan-niedermann we do so too on Android repos - like this one - https://github.com/nextcloud/android-common/blob/main/.github/workflows/gradle-wrapper-validation.yml

[stefan-niedermann]

Aah, it's a separate workflow, that's why I missed it 🙈

[AndyScherzinger]

Fun stuff....

getting the checks to turn green is a major pain - as expected since metadata quality on libraries / dependency management are rather poor, especially for Android / Google artifacts.

I'll keep working on it but might keep going for the approach to put them on a trusted list because there is no way for my to maintain checksums manually because they aren't available anywhere :(

[AndyScherzinger]

some artifacts, thanks Google can't be verified, so put them in a trusted list

[AndyScherzinger]

some keys aren't available via any dependency repo, so they will get added to an ignore list automatically

[AndyScherzinger]

same for found keys, they will be added to a trusted list