skip to content

Which checksum algorithms does Gradle support for verification, and which should you choose and why?

level: middleimportance: should knowfreq 40%

answer

  1. md5/sha1/sha256/sha512 supported
  2. md5 & sha1 broken (collisions)
  3. sha256 recommended default
  4. Gradle warns on md5/sha1-only
  5. multiple algos allowed, any-match passes

basics

~10 s

Gradle supports md5, sha1, sha256, and sha512. Prefer sha256 (or sha512). md5 and sha1 are cryptographically broken — collisions are feasible — so don't rely on them alone; Gradle even warns about them.

solid answer

~50 s

The verification-metadata XML accepts four checksum elements: `<md5>`, `<sha1>`, `<sha256>`, `<sha512>`. For integrity that resists deliberate tampering you want a collision-resistant hash, so **sha256 is the recommended default** and sha512 is the stronger option. md5 and sha1 are both broken — practical collision attacks exist — meaning an attacker could in principle craft a malicious artifact with the same md5/sha1 as a legitimate one. Gradle treats them as insecure: if a component is verified *only* by md5 or sha1, Gradle emits a warning, because relying on them defeats the purpose. They remain in the format because some legacy or third-party repositories only publish those weaker checksums, so you may record them as a supplementary signal while still requiring a strong hash. You can record multiple algorithms per artifact; verification passes if a recorded checksum matches. Bottom line: generate sha256 (optionally sha256,sha512) and don't depend on md5/sha1 for trust.

code

bash · 2 lines
bash
# Record both sha256 and sha512 per artifact
./gradlew --write-verification-metadata sha256,sha512 build

go deeper

for a junior

Name the four algorithms and that sha256 is the one to use.

for a middle

Explain collision resistance, why md5/sha1 are unsafe for tamper detection, and that Gradle warns about them.

for a senior

Discuss multi-algorithm recording semantics (any-match), legacy-repo compatibility, and policy-driven sha512.

for a principal

Set an org standard (sha256 baseline, sha512 where mandated), and a rule that md5/sha1 are never the sole trust basis; tie warnings into CI gating.

## The four supported algorithms Gradle's verification format defines exactly four checksum element types per `<artifact>`: - `<md5>` — 128-bit, **broken** - `<sha1>` — 160-bit, **broken** - `<sha256>` — 256-bit, **recommended** - `<sha512>` — 512-bit, **strongest** ## Why md5 and sha1 are unsafe for tamper detection A checksum used for *security* must be **collision-resistant**: it must be infeasible to find two different inputs with the same hash. Both md5 and sha1 have practical, demonstrated collision attacks (e.g. the SHAttered sha1 collision). That means a determined attacker could, at least theoretically, produce a malicious jar whose md5/sha1 matches a legitimate one, so a build verifying only against those would accept the malicious bytes. They're fine for catching *accidental* corruption but not for defending against an adversary — and dependency verification exists precisely to defend against adversaries. Because of this, Gradle **warns** when an artifact is verified using only md5 or sha1, nudging you toward sha256/sha512. ## Why they still exist in the format Not every repository publishes strong checksums. Some old or niche repos only expose md5/sha1 alongside an artifact. Gradle keeps these element types so you can *record what's available*, but the expectation is that you back them with a generated sha256 from your own download. ## Choosing - **Default: sha256.** It's collision-resistant, fast, and the size of the metadata stays reasonable. `--write-verification-metadata sha256` is the canonical bootstrap. - **sha512** when you want extra margin or organizational policy demands it: `--write-verification-metadata sha256,sha512`. Larger hashes, marginally slower, bigger file — usually overkill but harmless. - **Multiple algorithms** can coexist on one artifact. Verification succeeds if any recorded checksum matches the computed one; you don't have to satisfy all of them. Recording two strong hashes is belt-and-suspenders but the practical benefit over sha256 alone is small. ## Example ```xml <artifact name="lib-1.0.jar"> <sha256 value="e3b0c44298fc1c149afbf4c8996fb924..."/> <sha512 value="cf83e1357eefb8bdf1542850d66d8007..."/> </artifact> ``` ## Practical guidance Use sha256 everywhere; add sha512 only if a policy requires it. Never let md5/sha1 be the *sole* basis of trust — if you must include them for compatibility, ensure a strong hash is also present. If you see Gradle warning about insecure checksums, regenerate with sha256.

  • If an artifact records both sha256 and sha512, must both match?
    No. Verification passes if any recorded checksum for that artifact matches the computed value. Recording multiple algorithms is additive, not a logical AND.
  • Why does Gradle warn about md5/sha1 instead of just rejecting them?
    They're still valid for catching accidental corruption and some repos only publish them, so Gradle allows but warns — signalling they shouldn't be your sole trust anchor for tamper detection.

saying these in an interview costs you the question

  • Claiming md5/sha1 are fine for security because they 'still detect changes'.
  • Saying all recorded algorithms must match simultaneously.
  • Recommending md5 as a default because it's 'faster'.

context

resolving links…