Checksums and signatures
Artifex serves checksums for integrity verification and stores detached OpenPGP signatures for provenance verification. For how Gradle uses both mechanisms, see Verifying Dependencies.
Checksums
Every file in a repository has MD5, SHA-1, SHA-256, and SHA-512 checksums. Maven metadata has the same checksums. Maven and Gradle can use these values to verify the files that they download.
Artifex computes the checksums from the file, so all four are available regardless of which checksums your build uploaded. Artifex verifies an uploaded checksum against its file. If the values don't match, the deployment fails and the file isn't stored.
When Artifex fetches a file from a remote upstream, it also verifies the file against the checksums that the upstream publishes. Artifex stores the file only when they match. The file page shows which algorithms Artifex verified this way.
Signatures
A detached OpenPGP signature is deployed as a file beside the file that 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.ascMaven's GPG plugin and Gradle's signing plugin produce these files, and Artifex accepts them like any other file. A consumer can verify the JAR file against the signature by using their own tools and trusted copy of the public key.
A version page marks files that have a detached signature.
The file page for an .asc file shows its signature metadata:
| Field | Description |
|---|---|
| Key ID | The key that created the signature |
| Fingerprint | The key's fingerprint, if the signature carries it |
| Created | When the signature was created |
| Hash algorithm | The digest algorithm that was signed |
| Public key algorithm | The signing key's algorithm |
Artifex doesn't store your public keys or verify the signature against the artifact. Use the signature metadata to identify which key signed a release, not as proof that the signature is valid.
Advanced
A checksum is served at the file's path with .md5, .sha1, .sha256, or .sha512 added. The response is the hexadecimal digest followed by a newline, as text/plain.
When a client uploads a checksum during a deployment, a matching digest gets a 201 Created response and isn't stored; the file is the source of the digest. A digest that doesn't match, or a body that isn't a hexadecimal digest, gets a 400 Bad Request response that names the value that Artifex computed. A checksum for a file that isn't in the repository gets a 404 Not Found response. A checksum file can include a filename after the digest, which some tools write.
When an upstream's published checksum doesn't match the received bytes, the request gets a 503 Service Unavailable response.