skip to content

What exactly is a detached `.asc` signature, and how does Gradle make sure it gets uploaded alongside the artifact?

level: middleimportance: should knowfreq 35%

answer

  1. ASCII-armored = text .asc
  2. detached = separate file
  3. artifact stays byte-identical
  4. registered as publication artifact
  5. gpg --verify file.asc file

basics

~10 s

A detached .asc is a separate ASCII-armored PGP signature file sitting next to the artifact (e.g. lib.jar.asc). The signing plugin registers each .asc as a publication artifact, so publish uploads it automatically.

solid answer

~40 s

`.asc` is the conventional extension for an **ASCII-armored**, **detached** PGP signature: armored means it's printable text rather than raw binary, and detached means the signature lives in its own file instead of being wrapped around the data. So for `mylib-1.0.jar` you get `mylib-1.0.jar.asc`. Gradle ensures upload by **registering each generated `.asc` back onto the same publication** as an extra artifact during signing. Because it's now part of the `MavenPublication`'s artifact set, every `publish...` task that uploads the publication naturally includes the signatures with matching coordinates and the `asc` extension. A consumer or Sonatype's validation then runs `gpg --verify mylib-1.0.jar.asc mylib-1.0.jar` against your public key. The detached design is what lets the original artifact remain byte-identical to an unsigned build while still being verifiable.

code

bash · 5 lines
bash
$ ls build/libs
mylib-1.0.jar  mylib-1.0.jar.asc  mylib-1.0-sources.jar  mylib-1.0-sources.jar.asc

$ gpg --verify build/libs/mylib-1.0.jar.asc build/libs/mylib-1.0.jar
gpg: Good signature from "Your Name <[email protected]>"

go deeper

for a junior

Know .asc is a separate signature file next to the artifact.

for a middle

Explain detached + ASCII-armored, and that Gradle registers .asc as publication artifacts so they upload.

for a senior

Detail the registration-onto-publication mechanism and coordinate/extension handling, contrast with signing loose files.

for a principal

Tie detached signatures to reproducible builds and downstream verification policy.

## Detached vs embedded, armored vs binary PGP can produce signatures in a few forms. An **embedded** (clear-sign or wrapped) signature bundles the data and signature together; a **detached** signature is a standalone file containing only the cryptographic signature for some external data. Maven repositories use **detached** signatures so the artifact itself never changes. **ASCII-armored** (the `.asc` extension) encodes the binary signature as base64-ish printable text wrapped in `-----BEGIN PGP SIGNATURE-----` markers — friendlier for HTTP/text transports than the raw binary `.sig` form. ## What Gradle generates For each artifact in a signed publication, the `Sign` task produces `<artifact-name>.asc`. With `maven-publish` you'll see them under `build/libs/*.asc` for the jars and a signed POM under `build/publications/<name>/`. Each carries the same Maven coordinates as its source artifact but with extension `asc` (and the source's classifier, e.g. `sources`/`javadoc`). ## How upload is guaranteed The critical step is registration. When `signing` signs a publication, it doesn't just drop files on disk — it calls back into `maven-publish` to **add each `.asc` as an `MavenArtifact` on the publication**. So the publication's artifact list grows to include the signatures. Any `publishMavenPublicationTo<Repo>Repository` task iterates that list and uploads each entry, meaning signatures ride along automatically with no extra configuration. This is why signing the *publication* (not loose files) matters: loose files wouldn't be registered and wouldn't upload. ```bash # verify a downloaded artifact against its detached signature gpg --verify mylib-1.0.jar.asc mylib-1.0.jar # Good signature from "Your Name <[email protected]>" ``` ## Why detached matters for reproducibility Because the signature is detached, the published jar is bit-for-bit the same as the unsigned build output. Consumers who don't care about signatures ignore the `.asc`; those who do can verify provenance. Mirrors and CDNs can serve both files independently.

  • What does ASCII-armored mean and why use `.asc` over `.sig`?
    ASCII-armored encodes the binary signature as printable text wrapped in PGP markers. `.asc` is the armored form; `.sig` is raw binary. Maven repos use the text-friendly `.asc`.
  • How does the signature get the right Maven coordinates?
    Gradle registers each `.asc` as a publication artifact inheriting the source artifact's group/name/version/classifier with extension `asc`, so it uploads under matching coordinates.

saying these in an interview costs you the question

  • Saying the jar is modified or wrapped — detached signatures leave the artifact untouched.
  • Assuming you must manually upload `.asc` files — they're auto-registered onto the publication.

context

resolving links…