Maven Central requires every deployed file to carry a PGP signature and checksum files, plus project metadata such as license, developer and SCM details. Those rules prove the files were signed by someone holding a key and that the metadata exists. They do not prove the key owner is trustworthy or that the code is safe.
What publishers must provide
The Sonatype requirements page lists these items:
- Coordinates. A groupId, artifactId and version. A version cannot end in SNAPSHOT.
- Project information. A name, description and URL.
- License. The distribution license must be declared.
- Developer information. A developers section is required. A link to a code hosting profile is acceptable if there is no website.
- SCM information. Connection, developer connection and URL elements are required, though the URL itself does not need to be public.
- Sources and Javadoc. Non-pom projects supply matching sources and Javadoc jars. Placeholder jars are accepted.
- Checksums. MD5 and SHA1 files are required for every deployed file. SHA256 and SHA512 are optional.
- Signatures. All deployed files must be signed with GPG or PGP, with a matching .asc file for each.
What that tells you
A few things are real signals.
- Someone controls a signing key. Every file was signed with one.
- Files were not altered after signing. If a signature verifies against the key, the bytes match what was signed.
- There is a trail. The project declares a license, developers and an SCM location, so you know where to look.
What it does not tell you
Be careful with four assumptions.
- Key ownership. A valid signature shows that a key signed the file, not that the key belongs to the project you think. You need to know the expected key from a source you trust.
- Code safety. Signing says nothing about whether the code contains a flaw or malicious logic.
- Metadata truth. The SCM URL may not need to be public, and the metadata is declared by the publisher. Placeholder sources and Javadoc jars are accepted, so a sources jar is not proof that the binary was built from public source.
- Checksum strength. Required MD5 and SHA1 files catch accidents, but they are weak for adversarial settings. Prefer SHA256 or a signature where you can.
A practical review for a new Java dependency
- Confirm the groupId matches a domain or hosting account you recognize as the project's.
- Check the release history for a long gap followed by a sudden release.
- Compare the artifact against the project's own repository tags.
- Pin the exact version and record its hash in your own verification metadata or lockfile, so later changes are visible.
- Check whether the signing key stayed the same across releases. A change should have a public explanation.
Where tooling helps
Reading these details by hand does not scale across hundreds of transitive dependencies. Safeguard scans Maven and Gradle projects, produces SBOMs and applies policy gates, which gives you a consistent first pass before a person looks at the exceptions.
Quick check
Does a PGP signature mean a Maven library is safe?
No. It shows the files were signed by a key and were not changed since. It says nothing about the code quality or the key holder's intent.
Are sources jars proof of open code?
Not on their own. The requirements page says placeholder jars are accepted to pass validation, so compare with the project's repository.
Sources
Last reviewed: 19 October 2026.
