Validating ORAS CLI Binaries

Every ORAS release ships a checksums file, oras_<version>_checksums.txt, together with a detached GPG signature, oras_<version>_checksums.txt.asc. To validate a binary, check the signature of the checksums file, then check your download against the checksums file.

Newer releases are signed automatically by the release workflow with the ORAS Project Release Signing key (C6FC42F0DE84A345FAADB742F44418110791EF37). Earlier releases were signed manually with the key of an individual maintainer. All of these keys are listed in the KEYS file.

The following steps use v1.3.4 on linux_amd64 as an example. Replace the version and platform with the ones you downloaded.

Step 1: Import the release keys

$ curl -sSL https://raw.githubusercontent.com/oras-project/oras/refs/heads/main/KEYS | gpg --import -

Step 2: Check the imported keys

$ gpg --list-keys

The output lists every key in the KEYS file. Check that it includes the ORAS Project Release Signing key:

pub   ed25519 2026-07-13 [SC]
      C6FC42F0DE84A345FAADB742F44418110791EF37
uid           [ unknown] ORAS Project Release Signing <cncf-oras-maintainers@lists.cncf.io>

Some maintainer keys in the file have expired. See Expired keys below.

Step 3: Verify the checksums file

Download oras_1.3.4_checksums.txt and oras_1.3.4_checksums.txt.asc from the release, then run:

$ gpg --verify oras_1.3.4_checksums.txt.asc oras_1.3.4_checksums.txt
gpg: Signature made Thu Aug 27 19:35:31 2026 UTC
gpg:                using EDDSA key C6FC42F0DE84A345FAADB742F44418110791EF37
gpg: Good signature from "ORAS Project Release Signing <cncf-oras-maintainers@lists.cncf.io>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: C6FC 42F0 DE84 A345 FAAD  B742 F444 1811 0791 EF37

The Good signature line confirms the checksums file is authentic. The WARNING lines only mean that you have not marked the key as trusted in your local keyring; they do not mean that verification failed.

Step 4: Verify your download against the checksums file

Put the archive you downloaded in the same directory and run:

$ sha256sum --ignore-missing -c oras_1.3.4_checksums.txt
oras_1.3.4_linux_amd64.tar.gz: OK

On macOS, use shasum -a 256 --ignore-missing -c oras_1.3.4_checksums.txt.

Verifying a single artifact

Each archive and each SBOM (.sbom.json) in a release also has its own .asc signature. You can verify one directly:

$ gpg --verify oras_1.3.4_linux_amd64.tar.gz.asc oras_1.3.4_linux_amd64.tar.gz

Expired keys

A key that has since expired still validates signatures it made while it was valid. For example, v1.3.0 was signed with a maintainer key that has now expired:

$ gpg --verify oras_1.3.0_checksums.txt.asc oras_1.3.0_checksums.txt
gpg: Signature made Mon Sep  8 04:49:30 2025 UTC
gpg:                using ECDSA key 3E94D52AFA465877CAEA79F1E8052EA17ECB9A6C
gpg: Good signature from "Lixia (Sylvia) Lei <lixlei@microsoft.com>" [expired]
gpg: Note: This key has expired!
Primary key fingerprint: 3E94 D52A FA46 5877 CAEA  79F1 E805 2EA1 7ECB 9A6C

The Good signature line is what matters. The Note: This key has expired! line is not a verification failure.