Skip to content

Security

Dependency verification

Checksum verification

coursier verifies checksums for downloaded artifacts. It supports MD5, SHA-1, and SHA-256 checksums, which can be provided either via dedicated checksum files (.md5, .sha1, .sha256) available on the repository, or via HTTP response headers (X-Checksum-MD5, X-Checksum-SHA1, X-Checksum-SHA256) returned when downloading the artifact. When both a header checksum and a checksum file are available, the header checksum takes precedence. If no checksum is available at all, coursier accepts the artifact without checksum verification.

By default, coursier checks SHA-1 checksums, and accepts artifacts that have none. Note that checksums are fetched from the same server as the artifacts, so they protect against corrupted downloads, not against a repository serving tampered artifacts along with matching checksums.

Which checksum types are checked, and whether missing checksums are accepted, can be customized with a comma-separated list of checksum types, tried in order, the first one available for an artifact being the one checked. A trailing none accepts artifacts that have none of the listed checksums. Without it, a missing checksum is an error. This list can be passed:

  • via the COURSIER_CHECKSUMS environment variable, or the coursier.checksums Java property (the environment variable takes precedence),
  • via the --checksum option of the CLI commands that download artifacts,
  • via coursier's API, using the checksums field of FileCache (e.g. cache.copy(checksums = Seq(Some("SHA-256"), Some("SHA-1")))), whose default is read from the environment variable and Java property above.

For example, COURSIER_CHECKSUMS=SHA-256,SHA-1 checks SHA-256 checksums when a repository has them, SHA-1 ones otherwise, and fails on artifacts that have neither. Trying SHA-256 first costs an extra request for each artifact on repositories that don't have SHA-256 checksums, which is the case of most artifacts on Maven Central, so that this isn't the default. Note that a strict list (without none) also applies to downloads that come with no checksum at all, like the JVM archives cs java downloads.

Signature verification

coursier does not perform PGP signature verification. It is possible to make coursier fetch .asc signature files via the API, but no verification of those signatures is performed by coursier itself.

Verification metadata

coursier does not support a verification metadata approach comparable to Gradle's verification-metadata.xml. Support for this could be added in the future.

SCA tool integration

coursier does not currently generate a Software Bill of Materials (SBOM) during dependency resolution. But the Mill build tool, which uses coursier for dependency resolution, has early SBOM support.

CVE

As of writing this, coursier has been indirectly impacted by two CVEs: - CVE-2022-46751 - CVE-2022-37866

See the contact page if you need to reach coursier maintainers for urgent non-public security-related issues.

Artifact attestations

coursier uses the actions/attest-build-provenance GitHub action to attest that the binaries it distributes on its release pages were indeed built by the GitHub Action runners themselves. Attestations can be found here.

Users can validate a downloaded binary attestation with the GitHub CLI:

gh attestation verify /path/to/cs \
  -R coursier/coursier

If verification succeeds, the downloaded file digest matches an attested build subject and the attestation signature and certificate chain validate. You can add --format json to inspect the provenance details from the verified statement.