skip to content

What does the <configuration> block of verification-metadata.xml contain, and what do verify-metadata and verify-signatures control?

level: middleimportance: must knowfreq 45%

answer

  1. verify-metadata = check POM/.module too
  2. verify-signatures = PGP on top of checksums
  3. keyServers for public keys
  4. trusted-keys / trusted-artifacts exemptions
  5. policy header vs data

basics

~10 s

The <configuration> block holds global switches: <verify-metadata> toggles checking POM/module metadata files (not just jars), and <verify-signatures> turns on PGP signature checking in addition to checksums.

solid answer

~40 s

The `<configuration>` element is the first child of `<verification-metadata>` and carries the build-wide policy, separate from the per-artifact `<components>` data. The two headline toggles are `<verify-metadata>` and `<verify-signatures>`. `<verify-metadata>true</verify-metadata>` makes Gradle verify the **metadata** files — POMs, `.module` Gradle Module Metadata, Ivy descriptors — not only the binary jars; with it false, only artifacts you explicitly listed are checked. `<verify-signatures>false</verify-signatures>` controls whether Gradle additionally validates **PGP signatures**: when true, Gradle downloads each artifact's `.asc` signature and verifies it against trusted keys, which lets you trust by key rather than pinning a checksum for every version. The block can also hold `<keyservers>` entries (where to fetch public keys), `<key-servers enabled="...">`, `<trusted-artifacts>` exemptions, and `<trusted-keys>` mapping keys to components. So `<configuration>` = the rules; `<components>` = the data those rules apply to.

code

xml · 11 lines
xml
<configuration>
   <verify-metadata>true</verify-metadata>
   <verify-signatures>true</verify-signatures>
   <keyServers>
      <keyServer uri="https://keys.openpgp.org"/>
   </keyServers>
   <trusted-keys>
      <trusted-key id="6F538074CCEBF35F28AF9B066A0975F8B1127B83"
                   group="org.junit"/>
   </trusted-keys>
</configuration>

go deeper

for a junior

Know the two flags exist and that one adds PGP signature checking.

for a middle

Explain precisely what each flag verifies (jars-only vs metadata; checksum-only vs +PGP) and that keyServers/trusted-keys live here too.

for a senior

Discuss the trust trade-off: checksum-pinning vs key-trust, key-server availability/offline concerns, and when to set verify-signatures true.

for a principal

Set org policy: require verify-metadata true, decide on signature trust per publisher, manage key servers vs exported keyrings for hermetic/air-gapped builds.

## Role of <configuration> `verification-metadata.xml` has two halves. `<components>` is the bulk data — the trusted checksums/signatures per artifact. `<configuration>` is the **policy header** that decides *how* verification behaves globally. It is optional in theory but almost always present. ## <verify-metadata> Gradle resolves more than jars: it downloads **metadata** describing each dependency — Maven `.pom` files, Gradle Module Metadata `.module` files, and Ivy `ivy.xml`. These influence which transitive dependencies and variants are selected, so a tampered POM is a real attack vector. - `<verify-metadata>true</verify-metadata>` (the default when generated): Gradle verifies these metadata files too, requiring a trusted checksum entry for each. - `false`: Gradle skips metadata files and verifies only the artifacts you listed. This reduces the file size but leaves metadata unverified. ## <verify-signatures> There are two independent integrity mechanisms: - **Checksums** (sha256/sha512): pin exact bytes. Simple but must be updated for every new version. - **PGP signatures**: verify that an artifact was signed by a key you trust. With this on, you can trust a *publisher's key* and accept any version they sign without re-pinning a checksum each time. `<verify-signatures>`: - `true`: Gradle fetches the `.asc` signature for each artifact and validates it against the trusted keys (declared in `<trusted-keys>` or per-component `<pgp>` entries), consulting the configured key servers. Checksums act as a fallback for artifacts that lack a usable signature. - `false` (the conservative default): only checksum verification runs; signatures are ignored even if present. ## Other configuration children ```xml <configuration> <verify-metadata>true</verify-metadata> <verify-signatures>true</verify-signatures> <keyServers> <keyServer uri="https://keyserver.ubuntu.com"/> <keyServer uri="https://keys.openpgp.org"/> </keyServers> <trusted-keys> <trusted-key id="ABCDEF0123456789..." group="com.example"/> </trusted-keys> <trusted-artifacts> <trust group="com.example.internal"/> </trusted-artifacts> </configuration> ``` - `<keyServers>` — where to download public PGP keys (only relevant when `verify-signatures` is true). You can also set `<keyServers enabled="false"/>` to use only locally exported keys. - `<trusted-keys>` — maps a key id to the components it is allowed to vouch for. - `<trusted-artifacts>` — blanket trust exemptions (by group/name/regex) that skip verification entirely; use sparingly, e.g. for locally produced artifacts. ## Mental model `<configuration>` answers *what kinds of things do we verify, and how do we establish trust*; `<components>` answers *what are the concrete trusted values*.

  • If verify-signatures is true, are checksums still used?
    Yes. Signatures are the primary check, but Gradle keeps checksum entries as a fallback for artifacts that have no usable signature, so generated files often contain both.
  • What does verify-metadata=false sacrifice?
    POM/.module/ivy metadata files are no longer verified, so a tampered descriptor that alters transitive resolution would go undetected even though jars are still checked.

saying these in an interview costs you the question

  • Saying verify-signatures replaces checksums — it adds PGP; checksums remain as fallback.
  • Thinking verify-metadata controls the verification-metadata.xml file itself rather than dependency POM/.module files.

context

resolving links…