build(plugin): Add dependency locking and verification to `plugin-build` (GRADLE-104) by runningcode · Pull Request #1256 · getsentry/sentry-android-gradle-plugin

runningcode · 2026-06-03T15:29:48Z

Summary

Hardens the published plugin build against supply-chain risk by pinning its transitive dependencies, scoped to plugin-build/ (the build that produces the shipped artifact). Part of GRADLE-104 / SDK-1316.

Two complementary controls, both enforced automatically by existing CI (no workflow changes):

Gradle dependency locking — dependencyLocking { lockAllConfigurations() } plus a gradle.lockfile. STRICT mode (the default) fails the build on unexpected version drift.
Gradle dependency verification — gradle/verification-metadata.xml with a SHA-256 checksum for every resolved artifact (verify-metadata=true, verify-signatures=false — no PGP keyring to maintain).

The verification metadata captures the formatter (spotless), docs (dokka), and publish tooling in addition to the project configurations.

Why the version-matrix tests are exempt

Pinning protects the canonical build (the default versions that ship). But test-matrix-agp-gradle.yaml deliberately tests compatibility against a matrix of AGP / Kotlin / Gradle versions, set via the VERSION_AGP / VERSION_KOTLIN env vars (read in buildSrc/.../Dependencies.kt) and the gradle-version override. Those overrides intentionally diverge from the lockfile and the recorded checksums, so pinning and the matrix are fundamentally in conflict:

Locking: with VERSION_KOTLIN overridden, compileClasspath resolves e.g. kotlin-stdlib:2.3.21, but the lockfile pins {strictly 2.0.0} → Dependency version enforced by Dependency Locking failure.
Verification: the matrix (and the standalone -p plugin-build integration test) resolve artifacts that aren't in verification-metadata.xml (different SDK/AGP versions; the buildscript-classpath .module files) → Dependency verification failed.

So we keep pinning on the canonical build and exempt the version-varying jobs:

Locking is guarded to only apply when no VERSION_AGP / VERSION_KOTLIN override is present:

val isVersionOverrideBuild =
  System.getenv("VERSION_AGP") != null || System.getenv("VERSION_KOTLIN") != null
if (!isVersionOverrideBuild) {
  dependencyLocking { lockAllConfigurations() }
}

Verification is turned off on the version-matrix and standalone integration-test steps via --dependency-verification=off.

Canonical jobs (pre-merge, publish, the distribution build) keep strict locking and verification, so the protection that matters for the shipped artifact is fully enforced.

Notes for reviewers

After changing a dependency, regenerate the lockfile and verification metadata in one go:
./gradlew -p plugin-build resolveAndLockAll --write-locks --write-verification-metadata sha256.
This is now documented in CONTRIBUTING.md, and AGENTS.md links to it.
Local gotcha: version overrides only take effect with --no-daemon, because System.getenv() returns the daemon's startup environment (which is why CI, with a fresh daemon per job, behaves correctly).

🤖 Generated with Claude Code

linear-code · 2026-06-03T15:29:53Z

GRADLE-104

semgrep-code-getsentry · 2026-06-03T15:32:09Z

+io.grpc:grpc-stub:1.69.1=testRuntimeClasspath
+io.grpc:grpc-util:1.69.1=testRuntimeClasspath
+io.netty:netty-buffer:4.1.110.Final=testRuntimeClasspath
+io.netty:netty-codec-http2:4.1.110.Final=testRuntimeClasspath


High severity vulnerability introduced by a package you're using:
Line 100 lists a dependency (io.netty:netty-codec-http2) with a known High severity vulnerability. Fixing requires upgrading or replacing the dependency.

ℹ️ Why this matters

Affected versions of io.grpc:grpc-netty-shaded and io.netty:netty-codec-http2 are vulnerable to Allocation of Resources Without Limits or Throttling. Netty's HTTP/2 implementation fails to correctly track active streams when sending RST_STREAM in response to certain malformed control frames. An attacker can send, for example, WINDOW_UPDATE frames with a zero or overflow increment, HEADERS/DATA on a half-closed stream, or PRIORITY frames with invalid length to trigger RST_STREAMs; each reset decrements Netty's concurrent-stream counter even though the request is still processed. By repeating this on a single connection, the attacker can open an unbounded number of streams, exhausting CPU and memory and causing a denial of service. This is a protocol level attack.

References: GHSA, CVE

To resolve this comment:
Upgrade this dependency to at least version 4.1.124.Final at plugin-build/gradle.lockfile.

💬 Ignore this finding

To ignore this, reply with:

/fp <comment> for false positive

/ar <comment> for acceptable risk

/other <comment> for all other reasons

_{You can view more details on this finding in the Semgrep AppSec Platform here.}

0xadam-brown

Nice! Coordinate + content locks look great.

m: Two high-level suggestions:

[1] Could be nice to include a pre-merge workflow that warns folks if their lock file needs updating, ie, regenerate the lock file, diff against what's in the PR, and fail if changed.

[2] Have dependabot PRs self-heal w/r/t the lock file.

Eg, i) extract lock file generation into a script, ii) trigger a small workflow on pull_request from dependabot/* when gradle/, plugin-build/, or buildSrc/** change, and iii) re-run the script from (i). (Or whatever makes sense...)

[1] is optional, but I think we should do [2], lest our dependabot life become even busier. Either here or in a fast-follow is fine by me. Thoughts?

runningcode · 2026-06-09T10:45:02Z

Yeah those are good points.
For 1, I will update and add this
For 2, Dependabot supports Gradle lock files but not dependency verification.
I wonder if we should consider switching to Renovate since it supports lock files and dependency verification out of the box and is free on open source repos: https://docs.renovatebot.com/modules/manager/gradle/
Or otherwise drop the dependency verification from this PR.

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 92718d0. Configure here.}

0xadam-brown

Thanks for the updates 💯

A few non-blockers if you want them.

romtsn

LGTM, good stuff! If you want to take the renovate path, I'd already run it through legal a while ago, and it should be enabled for this repo. I don't think there's a requirement to use dependabot strictly.

Pin the transitive dependencies of the published plugin build to harden against supply-chain risk. Gradle dependency locking records resolved versions in a lockfile and fails the build (STRICT mode) on unexpected drift, while dependency verification checks a SHA-256 checksum for every resolved artifact. Scoped to plugin-build only, the build that produces the shipped artifact. The metadata captures the formatter (spotless), docs (dokka), and publish tooling in addition to the project configurations, so the existing CI enforces both controls without new workflow steps. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

…DLE-104) The compatibility test matrix overrides AGP/Kotlin/Gradle versions, which deliberately diverges from the lockfile and verification metadata of the canonical build. Guard dependency locking so it only applies when no VERSION_AGP/VERSION_KOTLIN override is set, and disable dependency verification on the matrix and standalone integration-test steps. Canonical builds (pre-merge, publish, distribution) keep strict locking and verification. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

Adding, removing, or bumping a dependency in plugin-build invalidates the lockfile and verification metadata, and STRICT-mode locking fails the build until both are regenerated. Document the single command that rewrites them and point the dependencyLocking block at the new section. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

An agent that bumps a dependency in plugin-build hits a STRICT-mode lock failure with no hint that a regenerate command exists. Add a pointer under Common commands and link to the CONTRIBUTING.md section for detail. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

… (GRADLE-104) A release cut had swept the entry into the released 6.10.0 block under Internal Changes. Move it to a new Unreleased section so the changelog gate finds it, and file it under Security since dependency pinning is supply-chain hardening rather than an internal cleanup. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

sentry · 2026-06-23T09:05:43Z

          cache-encryption-key: ${{ secrets.GRADLE_ENCRYPTION_KEY }}

      - name: Build the Release variants and integrationTest
-        run: gradle assembleRelease bundleRelease integrationTest
+        # Verification is disabled here because the matrix deliberately overrides
+        # AGP/Kotlin/Gradle versions, resolving artifacts not in the metadata.
+        run: gradle assembleRelease bundleRelease integrationTest --dependency-verification=off

      - name: Check sentry-debug-meta.properties inside APKs
        run: |


Bug: The publish-snapshot.yml workflow is missing the --dependency-verification=off flag required when running from the plugin-build directory, which will cause the snapshot publish to fail.
_{Severity: CRITICAL}

Suggested Fix

Add the --dependency-verification=off flag to the ../gradlew publishAllPublicationsToMavenCentralSnapshotsRepository command within the publish-snapshot.yml workflow. This will align it with the other workflows that run from the plugin-build directory and prevent dependency verification failures for buildscript artifacts.

Prompt for AI Agent

Review the code at the location below. A potential bug has been identified by an AI agent. Verify if this is a real issue. If it is, propose a fix; if not, explain why it's not valid. Location: .github/workflows/test-matrix-agp-gradle.yaml#L71-L79 Potential issue: The pull request introduces Gradle dependency verification but fails to apply the necessary `--dependency-verification=off` flag to all relevant workflows. Specifically, the `publish-snapshot.yml` workflow executes Gradle from the `plugin-build` directory, which resolves buildscript-classpath artifacts not captured in the verification metadata. While other workflows like `integration-tests-sentry-cli.yml` and `test-matrix-agp-gradle.yaml` were correctly updated to disable verification for this reason, the snapshot publishing workflow was overlooked. This omission will cause the snapshot publishing job to fail due to verification errors, breaking the ability to publish new snapshots.

Also affects:

.github/workflows/integration-tests-sentry-cli.yml:35~40

runningcode requested review from 0xadam-brown, adinauer, markushi and romtsn as code owners June 3, 2026 15:29

semgrep-code-getsentry Bot reviewed Jun 3, 2026

View reviewed changes

cursor Bot reviewed Jun 3, 2026

View reviewed changes

Comment thread plugin-build/build.gradle.kts

runningcode force-pushed the no/gradle-104-version-pinning branch from 12fc51b to 86ac005 Compare June 4, 2026 12:26

sentry Bot reviewed Jun 4, 2026

View reviewed changes

Comment thread plugin-build/build.gradle.kts

runningcode force-pushed the no/gradle-104-version-pinning branch from 86ac005 to 91533ad Compare June 4, 2026 12:49

sentry Bot reviewed Jun 4, 2026

View reviewed changes

Comment thread .github/workflows/integration-tests-sentry-cli.yml

runningcode changed the title ~~build(plugin): Add dependency locking and verification (GRADLE-104)~~ build(plugin): Add dependency locking and verification to plugin-build (GRADLE-104) Jun 4, 2026

0xadam-brown reviewed Jun 5, 2026

View reviewed changes

runningcode commented Jun 9, 2026

View reviewed changes

Comment thread .github/workflows/update-dependency-locks.yml Outdated

runningcode commented Jun 9, 2026

View reviewed changes

Comment thread .github/workflows/update-dependency-locks.yml Outdated

runningcode force-pushed the no/gradle-104-version-pinning branch from 3c44476 to 92718d0 Compare June 9, 2026 11:26

cursor Bot reviewed Jun 9, 2026

View reviewed changes

Comment thread .github/workflows/update-dependency-locks.yml Outdated

runningcode force-pushed the no/gradle-104-version-pinning branch from 92718d0 to 630801b Compare June 9, 2026 13:46

0xadam-brown approved these changes Jun 15, 2026

View reviewed changes

Comment thread .github/workflows/update-dependency-locks.yml Outdated

Comment thread .github/workflows/update-dependency-locks.yml Outdated

romtsn reviewed Jun 17, 2026

View reviewed changes

Comment thread CONTRIBUTING.md

romtsn approved these changes Jun 17, 2026

View reviewed changes

runningcode and others added 4 commits June 23, 2026 10:52

docs(changelog): Point entry to the correct PR number

a260502

Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>

runningcode force-pushed the no/gradle-104-version-pinning branch from 630801b to ed784fc Compare June 23, 2026 08:52

runningcode and others added 2 commits June 23, 2026 11:00

sentry Bot reviewed Jun 23, 2026

View reviewed changes

runningcode merged commit f8b2557 into main Jun 23, 2026
23 checks passed

runningcode deleted the no/gradle-104-version-pinning branch June 23, 2026 09:14

runningcode mentioned this pull request Jun 23, 2026

build(deps): Regenerate plugin-build locks on SDK bump (GRADLE-104) #1325

Merged

sentry-release-bot Bot mentioned this pull request Jun 25, 2026

publish: getsentry/[email protected] getsentry/publish#8696

Closed

3 tasks

Uh oh!

Uh oh!

Conversation

runningcode commented Jun 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why the version-matrix tests are exempt

Notes for reviewers

Uh oh!

linear-code Bot commented Jun 3, 2026

Uh oh!

semgrep-code-getsentry Bot Jun 3, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

0xadam-brown left a comment

Choose a reason for hiding this comment

Uh oh!

runningcode commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

0xadam-brown left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

romtsn left a comment

Choose a reason for hiding this comment

Uh oh!

sentry Bot Jun 23, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

runningcode commented Jun 3, 2026 •

edited

Loading

runningcode commented Jun 9, 2026 •

edited

Loading