How do you bootstrap sha256 checksums for an existing project, and what is the exact command?
answer
- --write-verification-metadata sha256 <task>
- task needed so Gradle actually resolves
- origin=Generated by Gradle
- merges, preserves existing entries
- review/commit; trust-on-first-use
basics
~10 sRun ./gradlew --write-verification-metadata sha256 help. Gradle resolves dependencies, computes sha256 for every downloaded file, and writes them into gradle/verification-metadata.xml. You then review and commit the file.
solid answer
~40 sUse the `--write-verification-metadata` command-line flag with a comma-separated list of algorithms, plus one or more tasks that trigger the resolutions you want covered: `./gradlew --write-verification-metadata sha256 help`. Gradle runs those tasks, downloads each artifact, hashes it, and appends `<sha256 value="…" origin="Generated by Gradle"/>` entries to `gradle/verification-metadata.xml`, creating the file if absent. Because a single task graph won't pull *every* configuration, people often target broad tasks (`build`, or a custom resolve task) or add `--write-verification-metadata sha256,sha512 build testClasses`. The output is a starting point you must **review** — the hashes are trust-on-first-use, so confirm versions and ideally cross-check against published checksums — and then commit so CI enforces them. Re-running the command after adding dependencies appends new entries without discarding existing ones.
code
bash · 8 lines# Bootstrap sha256 (and sha512) by running a broad task
./gradlew --write-verification-metadata sha256,sha512 build
# Re-run after adding deps to append new entries
./gradlew --write-verification-metadata sha256 help
# Then review the diff and commit
git add gradle/verification-metadata.xmlgo deeper
Recall the command ./gradlew --write-verification-metadata sha256 help and that it generates the metadata file.
Explain why a task argument is needed, that broad tasks cover more configurations, multiple algorithms can be requested, and entries merge rather than overwrite.
Raise the trust-on-first-use caveat, the review step, and iterating to capture missed configurations.
Define a team process: generation environment hygiene, mandatory review of the metadata diff in PRs, cross-checking high-value hashes, and when to escalate to signatures.
## The bootstrap problem You never hand-author checksums — there can be hundreds of artifacts (jars, poms, `.module` files, sources). Gradle generates them for you from a real resolution, and you review the result. ## The command ```bash ./gradlew --write-verification-metadata sha256 help ``` Breaking it down: - `--write-verification-metadata` puts Gradle into *recording* mode: instead of (only) verifying, it writes computed hashes into `gradle/verification-metadata.xml`. - `sha256` is the algorithm list. You may pass several: `sha256,sha512`. Gradle then records each requested algorithm per artifact. - `help` is just *a task to run*. The flag needs at least one task because Gradle only hashes artifacts it actually resolves while executing that task graph. ## Covering all your dependencies A tiny task like `help` resolves almost nothing, so in practice you pick tasks that exercise the configurations you care about: ```bash ./gradlew --write-verification-metadata sha256 build # or be explicit / broad ./gradlew --write-verification-metadata sha256 dependencies ``` Even so, configurations that are only resolved under specific conditions (a particular platform, an optional task, plugin classpaths) might be missed on the first pass. The usual workflow is iterative: run a build with verification on, see what's reported as missing, re-run `--write-verification-metadata` to capture it, repeat. ## What gets written For each resolved file Gradle adds an `<artifact>` under the right `<component>`, with the chosen checksum elements and `origin="Generated by Gradle"`: ```xml <component group="org.junit.jupiter" name="junit-jupiter-api" version="5.10.2"> <artifact name="junit-jupiter-api-5.10.2.jar"> <sha256 value="..." origin="Generated by Gradle"/> </artifact> <artifact name="junit-jupiter-api-5.10.2.module"> <sha256 value="..." origin="Generated by Gradle"/> </artifact> </component> ``` Existing entries are preserved; new ones are merged in. Components are kept sorted, which keeps diffs small and reviewable. ## Trust on first use The critical caveat: the generated hashes are only as trustworthy as the bytes Gradle downloaded *at generation time*. If a repository was already compromised when you bootstrapped, you've just frozen the malicious bytes. Mitigations: generate from a clean network/environment, review the diff (especially unexpected new components), and for high-value dependencies cross-check the recorded hash against the value published on the project's site or Maven Central. This trust-on-first-use weakness is the main reason teams add PGP signature verification on top. ## After bootstrapping Commit `verification-metadata.xml`. From then on every build (locally and in CI) re-hashes and compares, failing on any drift. To intentionally update — say after a dependency upgrade — you re-run `--write-verification-metadata` and review the resulting diff before committing.
- Why do you pass a task like `help` after the flag?The flag records hashes only for artifacts Gradle actually resolves while running the given task graph. A task is required to trigger resolution; broader tasks (build, dependencies) cover more configurations.
- What's the security risk of trusting the generated file blindly?It's trust-on-first-use: if the repo was already serving tampered bytes, you freeze them as 'correct'. Review the diff and cross-check critical hashes against published values; combine with signatures.
- Does re-running the command wipe existing entries?No — Gradle merges new entries into the existing file and preserves prior ones, keeping components sorted for clean diffs.
saying these in an interview costs you the question
- Saying you write the checksums manually.
- Forgetting the trailing task (the flag alone won't resolve anything meaningful).
- Treating the generated file as trustworthy without any review.