skip to content

What is the <trusted-artifacts> block in verification-metadata.xml for, and what are the risks of using it broadly?

level: seniorimportance: should knowfreq 30%

answer

  1. inside <configuration>
  2. <trust> = skip verification entirely
  3. group/name/version/file + regex + reason
  4. broad group-only rule = big hole
  5. differs from trusted-keys (which still verifies)

basics

~10 s

<trusted-artifacts> lists <trust> rules (by group, name, version, file, or regex) that exempt matching artifacts from verification entirely. It's useful for locally built or internal artifacts, but broad rules silently disable integrity checks.

solid answer

~50 s

`<trusted-artifacts>` sits inside `<configuration>` and contains `<trust>` elements that **skip** verification for any artifact they match. Each `<trust>` can filter on `group`, `name`, `version`, `file`, a `regex="true"` flag to treat those as patterns, and a `reason` for documentation. Typical legitimate uses: locally produced artifacts (`group="com.mycompany.internal"`), Gradle's own bootstrap files, or a specific snapshot you can't pin because its checksum changes. The risk is that a `<trust>` is a hole in the verification net: an artifact matched by it is accepted **without any checksum or signature check**, so an overly broad rule — e.g. trusting an entire popular group, or `regex` patterns that match more than intended — re-opens the supply-chain attack surface the file exists to close. Best practice: keep `<trust>` rules narrow (specific group+name, ideally a specific file), always add a `reason`, and review additions as carefully as any security change.

code

xml · 8 lines
xml
<configuration>
   <trusted-artifacts>
      <trust group="com.mycompany.internal"
             reason="locally built, unpublished"/>
      <trust file=".*-(javadoc|sources)[.]jar" regex="true"
             reason="non-binary, lower assurance accepted"/>
   </trusted-artifacts>
</configuration>

go deeper

for a junior

Know it exists to skip verification for some artifacts.

for a middle

Explain the matching attributes and the legitimate use cases (internal/local artifacts).

for a senior

Articulate the security trade-off, the difference from trusted-keys, and how to keep rules narrow with reasons.

for a principal

Define org governance: review process for trust edits, auditing, and a policy that forbids broad group-only exemptions on runtime dependencies.

## What it is Dependency verification defaults to *deny-by-default*: any artifact without a matching trusted checksum/signature fails the build. Sometimes that's too strict — you legitimately can't or don't want to pin certain artifacts. `<trusted-artifacts>` is the escape hatch. It lives inside `<configuration>`: ```xml <configuration> <trusted-artifacts> <trust group="com.mycompany" name="internal-lib" reason="built locally, no published checksum"/> <trust file=".*-javadoc[.]jar" regex="true" reason="docs not security-relevant"/> <trust group="org.gradle" reason="bootstrap artifacts"/> </trusted-artifacts> </configuration> ``` ## Matching attributes on <trust> - `group`, `name`, `version` — coordinate filters; omit one to match all values of it. - `file` — match a specific filename. - `regex="true"` — interpret the above as regular expressions instead of exact strings. - `reason` — free-text justification (not enforced, but invaluable for review). A `<trust>` with only `group` set trusts **every** artifact in that group at **any** version — a very wide hole. ## Why it exists (legitimate uses) - **Locally built / internal artifacts** that you produce and don't publish with checksums. - **Composite-build or snapshot artifacts** whose bytes change frequently, making checksum-pinning impractical. - **Non-security-relevant classified files** like `-javadoc.jar` or `-sources.jar` where teams accept lower assurance to reduce maintenance. - **Bootstrap artifacts** Gradle needs before normal verification applies. ## The risk: every <trust> is a bypass Whenever an artifact matches a `<trust>` rule, Gradle performs **no** checksum or signature verification on it. So: - `<trust group="com.google.guava"/>` would accept *any* Guava jar with *any* contents — exactly the swap attack verification is meant to stop. - A loose `regex` (`file=".*\.jar"`) could disable verification for nearly everything. - Rules accumulate over time; without review they quietly erode the guarantee. ## Trust-by-key vs trust-by-exemption Note the distinction from `<trusted-keys>`: a trusted **key** still *verifies* a signature (it just lets one key vouch for many components), whereas `<trusted-artifacts>` *skips verification altogether*. Prefer key- or checksum-based trust; reserve `<trusted-artifacts>` for cases that genuinely can't be pinned. ## Governance recommendations - Keep rules as specific as possible (group + name, ideally + file). - Always populate `reason`. - Treat edits to this block as security-sensitive code review. - Periodically audit for rules that have grown stale or too broad.

  • How does <trusted-artifacts> differ from <trusted-keys>?
    <trusted-keys> still verifies a PGP signature, just letting one key vouch for many components; <trusted-artifacts> skips all verification for matching files. The former preserves integrity guarantees, the latter removes them.
  • What's the danger of a <trust> rule with only a group attribute?
    It exempts every artifact in that group at every version, so a malicious replacement under that group would be accepted unchecked — defeating the purpose of verification.
  • When is trusting -javadoc/-sources jars considered acceptable?
    When teams judge them non-security-relevant (not on the runtime classpath) and want to cut maintenance; it's a deliberate, documented trade-off, ideally scoped by a precise file regex.

saying these in an interview costs you the question

  • Treating <trusted-artifacts> as just a convenience without acknowledging it disables verification.
  • Confusing it with <trusted-keys>, which still validates signatures.
  • Recommending broad group-only trust rules to silence verification failures.

context

resolving links…