SDK docs · sdk/18

Verify a release

Every release carries a manifest signed with MintID’s release key, naming each published package and image and its digest; verify it with the public key alone, then check what you installed against it.

Status

A MintID release is a public-v<date>[.<n>] tag of the public project, the package versions published from it, and the service images built from the same tree. Every release carries a release manifest signed with MintID's release key: one JSON document naming each artefact the release published and its digest. You verify the manifest with the release's public key alone — no account, no third-party service — and then check each package or image you use against it.

Status (13 October 2026). The signed release manifest ships with every public release from the first one after the release key is created; the key and its fingerprint are published on this page at that release, and until then no release carries a manifest. PyPI: every package is uploaded by trusted publishing (no stored upload token). npm: the registry signs every version; the versions carry no npm provenance attestation, so npm audit signatures verifies the registry signatures only — the manifest is the check. Images: every image of the services is signed by digest with the same release key and carries a signed CycloneDX SBOM; the images are not distributed publicly, and are given on request.

This line is the only place the status of release verification is stated; the other pages link here.

The release key

The public key is mintid-release.pub in the public project's SDK documentation, and each release also carries the copy it was verified with (release/<tag>/mintid-release.pub). Trust the key by its fingerprint, stated here, not by the file next to the manifest:

Release key fingerprint (SHA-256 of the public key, DER): 41aa9297b554d38701acedd4c8649b92ab672678643d9ed2518ed52d8fd20966

Download the public key (mintid-release.pub, PEM) and check it against the fingerprint with the command beside this paragraph.

The private half is an AWS KMS key (ECDSA P-256): it never leaves the key service, and only the release pipeline of the project can sign with it.

The release manifest

The public project's tree at tag <tag> holds the manifest of that release and its signature: the three files listed beside this paragraph.

Verify it first, with cosign (any recent version; nothing is fetched from the network).

Verified OK means the manifest is the one the release pipeline signed. --insecure-ignore-tlog=true only says there is no transparency-log entry to check — the signature is checked against the key, which is the point.

The manifest ("schema": "mintid.release-manifest/v1") names the release (release), the commit it was built from (source_revision, the same value the public tag's annotation cites), and:

Field	Each entry
`npm`	`name`, `version`, `integrity` — npm's `dist.integrity`, the SHA-512 of the tarball as the registry serves it
`pypi`	`name`, `version`, `filename`, `sha256` — PyPI's digest of that file
`images`	`name`, `repository`, `tag`, `digest`, `signature`, `sbom_attestation` and `sbom_sha256` (the SHA-256 of the SBOM in canonical JSON)
`web`	`name`, `path` (in the public project's tree), `size` and `sha256` — the browser check's WebAssembly module and its JavaScript glue

textsdk/18 · release/<tag>/

release/<tag>/release-manifest.json        what the release published
release/<tag>/release-manifest.json.sig    the release key's signature over it
release/<tag>/mintid-release.pub           the key it was verified with

bashsdk/18 · verify the manifest

cosign verify-blob --key mintid-release.pub \
  --signature release-manifest.json.sig \
  --insecure-ignore-tlog=true \
  release-manifest.json

Check a package against the manifest

npm — the registry's integrity must equal the manifest's (first box beside this paragraph), and a lock file records the same value for what you installed (package-lock.json, "integrity"). npm audit signatures checks the registry's own signature on top.

PyPI — download the file and compare its hash (second box). Then pin those hashes so nothing else can reach you later: pip install --require-hashes -r requirements.txt, with each line carrying --hash=sha256:<the manifest's value>.

bashsdk/18 · npm

npm view @mintid-net/verifier-client@<version> dist.integrity
jq -r '.npm[] | select(.name=="@mintid-net/verifier-client") | .integrity' release-manifest.json

bashsdk/18 · PyPI

pip download --no-deps -d wheels mintid-verifier-sdk==<version>
sha256sum wheels/*
jq -r '.pypi[] | select(.name=="mintid-verifier-sdk") | "\(.sha256)  \(.filename)"' release-manifest.json

Check the browser check against the manifest

The browser check's module and glue are files of the release's tree; the project's pipeline rebuilds them from the sources on every push to the main branch and fails if one byte differs from the committed files. Compare the files a page serves you, or the ones in the tree, with the manifest: the commands beside this paragraph run from the browser check's directory in the release's tree, where the module and its glue are in pkg/.

Service images

The services (verifier, issuer, chain node, MCP server, self-revocation relay) run from container images built by the project's pipeline. Each is signed by digest with the release key (the public testnet's images with a testnet key of their own), and its SBOM — the software it contains, in CycloneDX JSON, generated from the image itself — is attached as a signed attestation; the pipeline verifies both before it finishes. The manifest lists the production images built from the release's tree. The images themselves are not in a public registry: access to them is given on request, as the testnet's endpoints are (endpoints), to anyone with a reason to check them — an auditor, an operator, an integrator assessing the service.

With an image's $IMAGE@$DIGEST (the digest as the manifest names it), the three commands beside this paragraph verify the signature, the attestation and the SBOM's hash.

A signature also carries the commit the image was built from (source_revision) and, for the services that serve build-info, the release (release).

bashsdk/18 · verify an image

cosign verify --key mintid-release.pub --insecure-ignore-tlog=true "$IMAGE@$DIGEST"
cosign verify-attestation --type cyclonedx --key mintid-release.pub \
  --insecure-ignore-tlog=true "$IMAGE@$DIGEST" > /dev/null
cosign download attestation --predicate-type https://cyclonedx.org/bom "$IMAGE@$DIGEST" \
  | jq -r .payload | base64 -d | jq -cS .predicate | tr -d '\n' | sha256sum   # = sbom_sha256

Which release you are talking to

Every service built from a release names it: the verifier's GET /v1/build-info serves source_revision (the commit the image was built from) and release (the newest public-v* tag whose service sources are identical to it, or unreleased), and the issuer serves the same two fields on its own build-info route (given on request). Look that release's manifest up and you hold the digests of what answered. On the public testnet every deployment is also listed with its release (which release it runs).

npm provenance is not the verification path

npm can attach a sigstore "provenance" statement to a version, but its registry accepts one only from a public project's pipeline on a GitLab.com-hosted runner. MintID's releases are built and published by the project's own pipeline on its own infrastructure, so its versions carry no provenance statement. The signed manifest gives the same assurance — this artefact, these bytes, from this release's pipeline — under MintID's own key, for npm, PyPI and the images alike.

What this does not prove

A valid signature or a matching hash proves where an artefact came from and that it has not changed since; it says nothing about whether the code is correct. That is what the source, its tests and the scheduled audits are for (protocol state).