skip to content

Where do you obtain the correct SHA-256 to pin, and how do you verify you're pinning a trustworthy value?

level: middleimportance: should knowfreq 30%

answer

  1. official Gradle checksum/distributions page
  2. one sum per version + per bin/all type
  3. don't self-hash an untrusted download
  4. out-of-band trusted source
  5. review the sum in PR

basics

~20 s

Use the official SHA-256 that Gradle publishes for each distribution on its checksum/download pages. Copy the value for the exact version and archive type you're using; don't compute it from a download you don't trust.

solid answer

~40 s

Gradle publishes a `.sha256` value for every distribution archive on its official distributions/checksum reference pages — one per version and per type (`-bin.zip`, `-all.zip`). You pin that published value. The key trust point: don't just download the ZIP and hash it yourself, because if that download was already tampered with, you'd pin the attacker's hash and 'verify' successfully forever. The published checksum is the out-of-band source of truth, served over HTTPS from Gradle's own infrastructure. For higher assurance you can fetch the checksum over a separate channel/host than the artifact, and compare. Once you have the trusted value, prefer pinning it via the `wrapper` task (`--gradle-distribution-sha256-sum`) so the URL and sum stay consistent rather than hand-editing.

code

bash · 3 lines
bash
# Cross-check (not the source of trust): compare local hash to the OFFICIAL published value
sha256sum ~/Downloads/gradle-8.7-bin.zip
# -> must equal the sum published on Gradle's checksum page before you pin it

go deeper

for a junior

Know the value comes from Gradle's official published checksums, matched to your exact version.

for a middle

Explain the chicken-and-egg trust issue and why self-hashing an untrusted download is unsafe.

for a senior

Recommend out-of-band fetching and reviewing checksum changes in PRs as part of the upgrade flow.

for a principal

Define org policy: authoritative checksum source, who approves wrapper bumps, and review gates so a bad sum can't be merged silently.

## The chicken-and-egg trust problem A checksum only helps if the *expected* value is trustworthy. If you obtain the hash by computing it from a distribution you just downloaded, and that download was compromised, you'll pin the malicious hash — and every future verification will pass against the malicious artifact. So the expected value must come from a **trusted, out-of-band source**, not from the artifact you're verifying. ## The trusted source Gradle publishes the SHA-256 for each distribution on its official checksum reference / download pages. Each Gradle version exposes a checksum per archive type: - `gradle-8.7-bin.zip.sha256` - `gradle-8.7-all.zip.sha256` These are served over HTTPS from Gradle's infrastructure. Copy the value matching the **exact version and type** your `distributionUrl` points to. ## Raising assurance - Fetch the checksum from a *different* host/channel than the artifact when possible, so a single compromised host can't supply both a bad artifact and a matching bad hash. - Treat the checksum value as something to review in code review — a checksum change should accompany every wrapper version bump and be scrutinized. ## Don't self-compute from an untrusted download ```bash # ANTI-PATTERN: this pins whatever you downloaded, malicious or not sha256sum gradle-8.7-bin.zip # <-- do NOT trust this as your pin source ``` Computing the hash locally is fine as a *cross-check* against the published value, but the published value is the authority. ## Putting it together Once you trust the value, pin it via the wrapper task so `distributionUrl` and `distributionSha256Sum` are written consistently: ```bash ./gradlew wrapper --gradle-version 8.7 \ --gradle-distribution-sha256-sum <official-published-sum> ``` Then commit `gradle-wrapper.properties` and review the sum change in the PR.

  • Why is hashing your own downloaded ZIP a weak way to obtain the pin value?
    If that download was already tampered with, you'd pin the attacker's hash and every future check would pass. The expected value must come from a trusted out-of-band source, not the artifact itself.
  • Should the checksum change in code review?
    Only when the wrapper version/type changes. A checksum change without a version bump is suspicious and warrants scrutiny.

saying these in an interview costs you the question

  • Saying 'just sha256sum the ZIP you downloaded' as the source of the pin value.
  • Pinning a sum for the wrong version or wrong archive type.
  • Treating any checksum-looking string as trustworthy without an authoritative source.

context

resolving links…