Walk through the practical workflow for keeping verification-metadata.xml current as your project adds and upgrades dependencies over time. What goes wrong if you do it carelessly?
answer
- change dep → regenerate → review diff → commit together
- append-only; existing entries kept
- 'not in verification metadata' = forgot to regenerate
- poisoned-env generation bakes in bad trust
- prune stale entries periodically
basics
~20 sWhen you change dependencies, re-run --write-verification-metadata to append new entries, review the diff in your PR, and commit it. If you skip this, the build fails with 'artifact not in verification metadata'. Regenerating blindly can silently trust tampered artifacts.
solid answer
~40 sThe loop: (1) add or bump a dependency; (2) regenerate with `./gradlew help --write-verification-metadata pgp,sha256` (broad task set so all configs are covered) — Gradle appends entries for newly resolved artifacts, keeping existing ones; (3) inspect the diff as a security review — new checksums/key ids mean new trust; (4) commit the updated `verification-metadata.xml` (and keyring if using PGP) in the same PR as the dependency change. Failure modes: forgetting step 2 yields a hard build failure (`artifact ... not in dependency verification metadata`); regenerating on a poisoned cache or compromised mirror bakes the bad checksum into your trusted file — so generate from a clean environment and actually read the diff. Also clean stale entries periodically (`--dry-run` to preview, or remove unused components) so the file doesn't accumulate trust for dropped dependencies.
code
bash · 7 lines# After bumping a dependency, regenerate (broad task set, from root)
./gradlew help --write-verification-metadata pgp,sha256 --export-keys
# Preview first if unsure
./gradlew help --write-verification-metadata pgp,sha256 --dry-run
# Then: review the diff in gradle/verification-metadata.xml as a TRUST change, commit it in the same PRgo deeper
Know that adding a dependency means re-running the write command and committing the file, or the build fails.
Describe the full loop including reviewing the diff as a trust change and the 'not in metadata' failure mode.
Address generation-environment integrity, pruning stale entries, and keeping regeneration human-reviewed rather than bot-auto-committed.
Establish the org workflow: who reviews trust diffs, how bots (Renovate/Dependabot) interact with regeneration, and guardrails against poisoned-cache generation.
## Why this is a recurring chore The verification file is a frozen snapshot of trusted bytes. Every time your dependency graph changes — a direct bump, a new transitive, a plugin upgrade — there are artifacts Gradle has never recorded. Until you record them, builds that resolve them **fail closed**: ``` > Dependency verification failed for configuration ':runtimeClasspath': - On artifact lib-1.3.0.jar (com.acme:lib:1.3.0): artifact was not in dependency verification metadata. ``` ## The maintenance loop 1. **Change the dependency** (in `build.gradle(.kts)` or the version catalog). 2. **Regenerate**: ```bash ./gradlew help --write-verification-metadata pgp,sha256 --export-keys ``` Use a broad task set (and run from root in multi-project builds) so every configuration's artifacts are captured. Gradle **appends** entries for new artifacts and leaves existing ones intact. 3. **Review the diff** — this is the security step. New `<sha256>` values and `<pgp>`/`<trusted-key>` ids are *new trust*. Ask: do I expect this dependency? Is the signer plausible? 4. **Commit** the updated `verification-metadata.xml` (plus keyring files) in the **same PR** as the dependency change, so the trust update is reviewed together. ## What goes wrong when careless - **Skipping regeneration** → hard `not in verification metadata` failures for teammates and CI. - **Regenerating on a compromised environment** → the malicious artifact's checksum is recorded as trusted. The write mode trusts whatever it sees, so generation environment integrity matters. Generate from a clean machine and read the diff. - **Blind `git add -A` of a huge diff** → defeats the purpose; you've rubber-stamped trust changes. - **Letting the file rot** → entries for removed dependencies linger, growing the trusted surface. Periodically prune unused components; some teams regenerate fresh and diff against the old to catch drops. ## Tips - `--dry-run` with the write flag previews changes. - Keep the diff small per PR by regenerating right after each dependency change rather than batching many. - Automate the *failure* detection in CI (verification on), but keep regeneration **human-reviewed**, not auto-committed by a bot without inspection.
- What is the exact symptom of forgetting to regenerate after adding a dependency?The build fails closed with 'Dependency verification failed ... artifact was not in dependency verification metadata' for the new artifact, on the configuration that resolves it. The fix is to re-run --write-verification-metadata and commit the result.
- Why does the environment you regenerate from matter for security?Write mode records whatever bytes it resolves as trusted, without failing on mismatch. If your cache/mirror is compromised at generation time, you bake the malicious checksum into the trusted file. Generate from a clean environment and review the diff.
- How do you keep the file from accumulating stale trust?Periodically prune entries for removed dependencies — e.g. regenerate fresh and diff against the old file to spot drops, or manually remove unused <component> blocks — so the trusted surface stays minimal.
saying these in an interview costs you the question
- Auto-committing regenerated metadata via a bot without any human review of the diff.
- Regenerating from a developer machine with an unknown/poisoned cache and trusting the output.
- Thinking regeneration overwrites all entries (it appends/merges, keeping existing trust).