Checksums and signatures

Artifex computes every checksum that Maven clients use, and it shows what a detached signature next to a file says about itself.

Served checksums

Every file in a repository has a checksum at each of the following paths:

Path	Algorithm
FILE.md5	MD5
FILE.sha1	SHA-1
FILE.sha256	SHA-256
FILE.sha512	SHA-512

The response is the hex digest followed by a newline, with the content type text/plain; charset=utf-8.

The digests are computed from the bytes that Artifex holds, so a checksum can't disagree with the file it belongs to. This is true whether or not your client uploaded a checksum, and which algorithms it uploaded doesn't matter: a file deployed with only a SHA-1 still answers for SHA-512.

A generated maven-metadata.xml has checksums too, computed from the document that's served.

Checksums that a client uploads

When a client uploads a checksum during a deploy, Artifex checks it against the file:

• A digest that matches answers 201 Created. The upload isn't stored; the file is the source of the digest.
• A digest that doesn't match answers 400 Bad Request and names the value that Artifex computed.
• A body that isn't a hex digest answers 400 Bad Request.
• A checksum for a file that isn't there answers 404 Not Found with the message Upload the file before its checksum.

So a corrupted upload is refused at the moment it happens, rather than turning into a dependency that fails to verify in someone else's build.

A checksum file may carry a file name after the digest, which is what some tools write, and it's accepted.

Checksums from upstreams

When a file arrives from a remote upstream, Artifex also asks for the checksums that the upstream publishes and compares them with the bytes that arrived. A mismatch means the file isn't kept and the request answers 503 Service Unavailable.

The file page shows which algorithms were verified this way, so you can see whether an upstream backed up what it sent.

Signatures

A detached OpenPGP signature is deployed as a file next to what it signs, with .asc added to the name:

com/example/hello/1.0.0/hello-1.0.0.jar
com/example/hello/1.0.0/hello-1.0.0.jar.asc

Maven's GPG plugin and Gradle's signing plugin produce these files, and Artifex accepts them like any other file. Both are deployed and both are served, so a consumer can verify the jar against the signature with their own tools and their own copy of your public key.

A version page marks the files that have a signature next to them.

The file page of a .asc file shows what the signature says about itself:

Field	What it is
Key ID	The key that made the signature
Fingerprint	The key's fingerprint, when the signature carries it
Created	When the signature was made
Hash algorithm	The digest algorithm that was signed
Public key algorithm	The algorithm of the signing key

These fields are read from the signature file. Artifex doesn't hold your public keys and doesn't check the signature against the artifact; verification is done by whoever trusts the key. Treat the fields as a way to see which key signed a release, not as proof that the signature is good.