What role does PGP signing via the maven-gpg-plugin play in supply-chain integrity, and how does signature verification differ from checksum verification?
answer
- private key signs, public key verifies
- detached .asc per artifact
- authenticity, not just integrity
- Central requires signatures
- key trust/rotation is the hard part
basics
~20 sThe maven-gpg-plugin signs your artifacts with a private PGP key, producing .asc files. Consumers verify the signature with your public key, proving the artifact came from you and wasn't altered — something a plain checksum cannot prove.
solid answer
~50 sPGP signing adds authenticity on top of integrity. The maven-gpg-plugin runs (typically in the verify phase) and produces a detached .asc signature for each artifact using your private key. Publishing to Maven Central actually requires these signatures. Verification uses your trusted public key: it confirms both that the bytes are unchanged AND that they were signed by the holder of the corresponding private key — i.e. authenticity, which checksums alone cannot give because anyone who controls the repo can also publish a matching checksum. The hard part is key trust and distribution: a signature is only meaningful if consumers have an authentic copy of your public key and the key isn't compromised. Practically, sign releases (not snapshots) via a profile, manage the private key securely (HSM/CI secret, never in the repo), and on the consuming side enforce signature checks (e.g. a verification plugin) for critical dependencies.
code
xml · 12 lines<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>3.2.4</version>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals><goal>sign</goal></goals>
</execution>
</executions>
</plugin>go deeper
Knows the gpg plugin produces .asc signature files for artifacts.
Can wire the plugin in a release profile and pass the passphrase in CI.
Explains authenticity vs integrity, consuming-side verification, and the key-trust problem.
Owns key lifecycle (rotation, HSM, expiry), mandates verification of critical dependencies, and integrates signing into the release governance.
## Signing vs checksums A **checksum** answers: *do these bytes match the published hash?* (integrity). A **PGP signature** answers: *were these exact bytes signed by the holder of a specific private key?* (integrity **plus authenticity**). The crucial difference: an attacker who can write to the repository can forge a matching checksum, but cannot produce a valid signature without the private key. ## How signing works PGP (here, GnuPG) uses an asymmetric keypair: - The **private key** signs. It must stay secret (CI secret store, HSM, or a developer's protected keyring). - The **public key** verifies. It's distributed to consumers (and to public keyservers for Central). The **maven-gpg-plugin** binds the `sign` goal to a build phase (commonly `verify`) and emits a **detached signature** (`foo-1.0.jar.asc`, `foo-1.0.pom.asc`) for each produced artifact. Publishing to **Maven Central requires** these `.asc` files. ```xml <profile> <id>release-sign</id> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-gpg-plugin</artifactId> <version>3.2.4</version> <executions> <execution> <id>sign-artifacts</id> <phase>verify</phase> <goals><goal>sign</goal></goals> </execution> </executions> </plugin> </plugins> </build> </profile> ``` The passphrase is supplied non-interactively in CI, e.g.: ```bash mvn -Prelease-sign verify -Dgpg.passphrase=$GPG_PASSPHRASE ``` ## Verification on the consuming side Producing signatures is only half the story. To actually defend YOUR builds you must **verify** the signatures of dependencies you consume. This requires: 1. An authentic copy of each publisher's **public key** (the trust anchor). 2. A mechanism to check `.asc` files during resolution — e.g. a signature-verification step/plugin for critical artifacts, or repository-manager policies that reject unsigned/invalid artifacts. ## The hard problem: key trust A signature is only as trustworthy as the key behind it: - If you fetch the public key from the same compromised channel as the artifact, you've gained nothing. - A leaked or unrotated private key lets an attacker sign malicious artifacts. - Practical hygiene: protect the private key (never commit it; use CI secrets/HSM), set key expiry and rotate, publish the public key to well-known keyservers, sign **releases** rather than throwaway **snapshots**. ## Where it fits in the defense stack - **Source locking** (mirrors) → you only talk to a trusted repository. - **Checksums (-C)** → bytes weren't corrupted/swapped vs the published hash. - **PGP signatures** → bytes were authored by a trusted key. Together they cover transit corruption, repository compromise, and authorship — which is why mature supply-chain policies use all three.
- Why does signing alone not protect your build if you only consume dependencies?Signing protects artifacts YOU publish. To protect what you consume you must verify the publishers' signatures against their trusted public keys — production of signatures and verification of them are separate concerns.
- Why sign releases but typically not snapshots?Snapshots are mutable, frequently rebuilt, and not meant for external trust; signing them adds overhead and noise. Releases are immutable, distributed, and are what consumers actually trust and (for Central) are required to sign.
- What undermines the value of a signature even if it verifies?A compromised or leaked private key, or fetching the public key from an untrusted channel — the signature is only as trustworthy as the key and its distribution.
A checksum is a tamper-evident seal that anyone can re-make; a PGP signature is a wax seal stamped with a signet ring only you possess — forgeable only by stealing the ring (private key).
saying these in an interview costs you the question
- Saying signatures and checksums are interchangeable (signatures add authenticity).
- Committing the private key or passphrase to the repo.
- Assuming generating .asc files protects your consuming build without any verification step.