Signing Plugin Basics

## 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.