skip to content

At a basic level, what does the Gradle signing plugin produce, and why does publishing to Maven Central require it?

level: juniorimportance: must knowfreq 40%

answer

  1. detached PGP signature = .asc file
  2. signs jar + POM + sources + javadoc
  3. Central mandates signatures
  4. integrity + provenance
  5. needs secret key + passphrase

basics

~10 s

It produces a detached PGP signature (.asc file) for each artifact (jar, POM, sources, javadoc). Maven Central requires these signatures so consumers can verify the artifacts are authentic and untampered.

solid answer

~40 s

The signing plugin creates a **detached PGP signature** — a `.asc` file — alongside every artifact you publish: the main jar, the POM, and the sources/javadoc jars. To do that it needs a **PGP secret key** and its **passphrase**, which you provide either via the local gpg tool (`useGpgCmd()`) or directly in memory (`useInMemoryPgpKeys(key, password)`). Maven Central **mandates** these signatures: it rejects releases whose artifacts aren't signed by a key whose public half is published to a keyserver. The point is **provenance and integrity** — anyone downloading your library can verify the bytes were produced by you and weren't altered in transit. So in any publishing setup, you choose a key source (gpg vs in-memory) and let the plugin attach the `.asc` files during `publish`.

code

kotlin · 8 lines
kotlin
signing {
    // choose ONE key source, then sign the publications
    useInMemoryPgpKeys(
        System.getenv("SIGNING_KEY"),
        System.getenv("SIGNING_PASSWORD"),
    )
    sign(publishing.publications)
}

go deeper

for a junior

State that it makes .asc signatures for artifacts and that Central requires them for trust.

for a middle

Explain that every artifact (jar/POM/sources/javadoc) is signed and that you must supply a secret key + passphrase via one of the two key sources.

for a senior

Connect signing to provenance/integrity and keyserver-published public keys for validation.

for a principal

Frame signing within supply-chain trust and release governance across the org.

## What a signature is here A **PGP signature** is a cryptographic stamp made with your **secret key** that anyone can verify with your **public key**. A *detached* signature lives in its own file (extension `.asc`) next to the artifact it covers, rather than being embedded. The Gradle signing plugin's job is to generate one `.asc` per published file. ## What gets signed When you publish a typical Java library you produce several files — the binary jar, the **POM** (metadata), and usually **sources** and **javadoc** jars. Central requires *all* of them to be signed, so the plugin emits a matching `.asc` for each: `mylib-1.0.jar.asc`, `mylib-1.0.pom.asc`, and so on. ## Why Central requires it Maven Central is a public, widely-mirrored repository. Consumers must be able to trust that an artifact really came from the stated publisher and wasn't tampered with. PGP signatures provide that **integrity + provenance** guarantee: the validation service checks each `.asc` against the **public key** you've uploaded to a public keyserver. Missing or invalid signatures cause the release to be rejected. ## The two ingredients you must supply To sign, the plugin needs: 1. the **secret signing key**, and 2. its **passphrase**. There are two ways to supply them, which is the heart of this topic: - `useGpgCmd()` — use the locally installed gpg tool, keyring, and agent (good for laptops). - `useInMemoryPgpKeys(secretKey, password)` — hand Gradle the ASCII-armored key + passphrase directly (good for CI). ## Minimal wiring ```kotlin plugins { signing; `maven-publish` } signing { useInMemoryPgpKeys(System.getenv("SIGNING_KEY"), System.getenv("SIGNING_PASSWORD")) sign(publishing.publications) } ``` After this, running `publish` produces the artifacts plus their `.asc` signatures, ready for Central's validation.

  • What file extension do the generated signatures use?
    .asc — a detached ASCII-armored signature file produced next to each published artifact.
  • What two things must the signing plugin be given to sign?
    The PGP secret signing key and its passphrase — supplied either via useGpgCmd() (local gpg) or useInMemoryPgpKeys(key, password).

A signature is like a wax seal on a letter: the public key lets anyone confirm the seal is yours and the envelope wasn't opened. Central won't accept an unsealed letter.

saying these in an interview costs you the question

  • Saying the plugin signs with the public key — signing uses the secret/private key.
  • Thinking only the jar is signed and not the POM/sources/javadoc.
  • Believing Central will accept unsigned release artifacts.

context

resolving links…