skip to content

What does the Gradle `signing` plugin do, and why do you need it when publishing to Maven Central?

level: juniorimportance: must knowfreq 60%

answer

  1. detached .asc per artifact
  2. plugins { signing }
  3. sign(publications)
  4. Maven Central rejects unsigned
  5. integrity + authenticity

basics

~10 s

The signing plugin uses PGP/GPG to create detached .asc signature files for your build artifacts. Maven Central requires every published file to be signed so consumers can verify authenticity.

solid answer

~50 s

The `signing` plugin (`apply` it via `plugins { signing }`) generates a **detached PGP signature** — a separate `.asc` file — for each artifact it's told to sign. You declare what to sign in a `signing { }` block, typically `sign(publishing.publications["maven"])`, which signs the POM, JAR, sources and javadoc jars and registers each `.asc` as an additional publishable artifact. The point is **integrity and authenticity**: a consumer (or Maven Central's validation) can use your public key to verify a file was published by you and wasn't tampered with in transit. Maven Central (Sonatype) **rejects** any release that isn't accompanied by valid signatures, so for OSS publishing the plugin is effectively mandatory. It does nothing on its own until you also provide a key — but the plugin's job is purely producing and attaching the signatures.

code

kotlin · 8 lines
kotlin
plugins {
  `maven-publish`
  signing
}

signing {
  sign(publishing.publications["maven"])
}

go deeper

for a junior

Know that the plugin makes .asc files and that Maven Central demands them.

for a middle

Explain detached vs embedded signatures and the sign(publication) wiring that attaches .asc as artifacts.

for a senior

Connect it to supply-chain integrity, where keys come from, and how publish depends on the Sign tasks.

for a principal

Frame signing within org-wide artifact provenance/supply-chain policy and key custody governance.

## What signing means here A **PGP signature** is a cryptographic proof, created with a private key, that a specific byte sequence came from the key's owner and hasn't changed. A **detached** signature stores that proof in a separate file (extension `.asc`) rather than wrapping the original — so `mylib-1.0.jar` is published unchanged alongside `mylib-1.0.jar.asc`. Anyone holding the matching **public key** can verify the pair. ## Why Maven Central requires it Maven Central is a public, immutable, widely-mirrored repository. To protect millions of downstream builds from supply-chain tampering, Sonatype's validation **rejects any release artifact that lacks a valid `.asc` signature** verifiable against a public key published to a keyserver. So if you publish OSS to Central, signing is not optional. ## The plugin Apply it with the plugins DSL: ```kotlin plugins { `maven-publish` signing } ``` This adds a `signing { }` extension and creates `Sign` tasks on demand. You tell it *what* to sign: ```kotlin signing { sign(publishing.publications["maven"]) } ``` `sign(publication)` signs **every artifact** in that publication — main jar, sources jar, javadoc jar, and the generated `.pom` — and **registers each resulting `.asc` as an extra artifact** of the publication, so `publish` uploads them automatically. ## How it fits the build The plugin wires a `Sign` task (e.g. `signMavenPublication`) and makes the `publish` tasks depend on it, so the signatures exist before upload. The actual key material (which key, the passphrase) is supplied separately via `gradle.properties` (`signing.keyId`, `signing.password`, `signing.secretKeyRingFile`) or in-memory configuration — that key-supply mechanism is a separate concern; the plugin itself just orchestrates *producing and attaching* the signatures. ## Verifying locally After a build you'll find files like `build/libs/mylib-1.0.jar.asc`; `gpg --verify mylib-1.0.jar.asc mylib-1.0.jar` confirms a good signature.

  • What files does signing a publication produce?
    One detached `.asc` file per artifact in the publication — the main jar, sources jar, javadoc jar and the generated POM each get a corresponding `.asc`, all registered as extra publishable artifacts.
  • Does the signing plugin modify the original jar?
    No. Detached signatures live in separate `.asc` files; the original artifacts are published byte-for-byte unchanged.

saying these in an interview costs you the question

  • Thinking signing encrypts the artifact — it produces a verification signature, not encryption.
  • Believing the plugin embeds the signature inside the jar — signatures are detached `.asc` files.

context

resolving links…