Use GPG when your ecosystem requires it, such as Maven Central, which needs a signature file for each deployed file. Use Sigstore keyless signing when you build in CI and want no long-lived key to guard. Many projects need both, for different audiences.
The core difference
GPG signing relies on a key pair you create and keep. The signature proves the holder of that key signed the file. Your job is to protect the private key, back it up and tell users which public key to trust.
Cosign keyless signing binds a signature to an identity instead. Per the Sigstore documentation, cosign creates an in-memory key pair and gets an identity token, Fulcio issues a certificate that binds the ephemeral public key to the signer's identity, and the private key is destroyed shortly after. The signing event goes into Rekor, a public transparency log.
Comparison
| Question | GPG | Sigstore keyless |
|---|---|---|
| Long-lived private key to protect | Yes | No |
| Who is trusted | The key holder | An identity, such as a workflow, via a certificate |
| How users verify | Import your public key, check the signature | Check certificate identity and issuer |
| Public log of signing | No | Yes, in Rekor |
| Needed by some ecosystems | Yes, Maven Central needs .asc signatures | Not a substitute there |
| Works offline for the signer | Yes | Needs identity service access at signing time |
| Key loss or theft | Major incident, rotate and re-announce | No key to lose, but the CI identity must be protected |
What users type to verify
For a keyless blob signature, the Sigstore docs show a command of this shape:
cosign verify-blob FILE --bundle artifact.sigstore.json \
--certificate-identity=SIGNER_IDENTITY \
--certificate-oidc-issuer=ISSUER_URL
The identity and issuer flags are the point. They state who you expect to have signed. The docs list the GitHub issuer as https://github.com/login/oauth, so check the issuer value that matches how you sign, as a workflow identity may use a different issuer than a personal login.
Maven Central as a concrete case
The Maven Central requirements page says each deployed file needs a matching .asc signature, and that each file needs hex encoded .md5 and .sha1 checksum files. If you publish Java libraries, you will sign with GPG there whatever else you do.
A practical combination
- Sign with GPG where a registry demands it.
- Add a keyless signature or attestation for your GitHub release files. See how to sign release files with cosign sign-blob.
- Publish how to verify, with the exact identity to expect, in your README.
- If you keep a GPG key, store it on hardware or in a cloud key service. See where to keep code signing keys.
- Remember what a signature proves. See what signed commits prove and do not prove for the same lesson on commits.
A signature says who, not whether the code is safe. Safeguard dependency scanning and SBOM generation address the second question, and the free scan at gold.safeguard.sh/scan is a quick check.
Quick check
Is keyless signing less secure because there is no key?
It moves trust to the identity. If an attacker controls your CI identity they can sign, so protect the workflow.
Can I drop GPG on Maven Central?
The requirements page lists a .asc signature for each deployed file, so plan to keep GPG there.
Sources
- Sigstore Docs: Signing overview
- Sigstore Docs: Verifying signatures
- Sonatype: Maven Central publishing requirements
Last reviewed: 19 October 2026.
