Commit dcff043

# Every index the stitch repinned the tree on is signed by digest with

# this job's OIDC identity, and the SBOM attestation each carries is read

# back into one archive, before anything is uploaded: a signature that

# does not verify, or an image that lost its SBOM, fails the job with no

# asset uploaded. The checksums hack/upload-assets.sh signs next cover

# the archive and the image list. The signature over an index covers its

# attestation manifest, and promotion copies the digest within the same

# repository, so the stable release needs no signing step of its own.

- name: Sign the release images and collect their SBOMs

if: needs.build-amd64.outputs.release_exists == 'false'

run: |

env:

DOCKER_CONFIG: ${{ runner.temp }}/.docker

REGISTRY: ghcr.io/cozystack/cozystack

| `hack/sign-release-images.sh` | all three shapes, first-party | sign every pinned digest keylessly after the stitch, skipping one that already verifies, or with `--verify-only` fail a promotion whose rc images are unsigned; `--list` writes the `cozystack-images.txt` release asset |

| `hack/collect-image-sboms.sh` | all three shapes, first-party | read the SBOM attestation of every pinned index into the `cozystack-images-sbom.tar.gz` release asset, one document per platform; an image missing one for any platform its index serves fails the release |

A release cut from a tree that has [`hack/sign-release-assets.sh`](../hack/sign-release-assets.sh) carries three files beside its other assets, which [`hack/upload-assets.sh`](../hack/upload-assets.sh) has that script write before it uploads anything, and one cut from a tree that also has [`hack/sign-release-images.sh`](../hack/sign-release-images.sh) and [`hack/collect-image-sboms.sh`](../hack/collect-image-sboms.sh) carries two more, which `tags.yaml::prepare-release` writes before the upload. Releases cut before them have none of these files, and neither does a maintenance line until the scripts are backported to it (see below).

- `cozystack-images.txt` lists every first-party container image the release pins, one `<repository>@<digest>` per line: the multi-arch indexes [`hack/stitch-multiarch.sh`](../hack/stitch-multiarch.sh) repinned the tree on, which is what a cluster installed from this release pulls. The packages artifact and the installer chart are not in it.

- `cozystack-images-sbom.tar.gz` holds the SPDX SBOM of each image in that list, as `<image>.<os>-<arch>.spdx.json`, one document per platform, read from the attestation BuildKit attached to the image at build time (`SBOM=1` in `tags.yaml`, the scanner pinned in [`hack/common-envs.mk`](../hack/common-envs.mk)). These documents come from the syft inside that scanner, the source SBOM from the syft the workflow installs, so the two need not agree on a version. An image without a document for every platform its index serves fails the release instead of being left out.

- `cozystack-checksums.txt` holds the SHA-256 of every other asset, the SBOMs and the image list among them.

The container images a release pins by digest each carry an SPDX SBOM of the packages in them, which BuildKit attaches at build time as an attestation (`SBOM=1` in `tags.yaml`, scanner and flags in [`hack/common-envs.mk`](../hack/common-envs.mk)). The attestation is an entry of the image's index, so the digest the release pins names both, and promotion copies it with the image. Read it with `docker buildx imagetools inspect <image>@<digest> --format '{{ json .SBOM }}'`, which prints one document per platform. They carry no signature of their own: the signature over the index covers them, see [Image signatures](#image-signatures). A release cut before `SBOM=1` was set has none, and neither has the Talos installer image, which the imager builds and `skopeo` pushes, nor the third-party images `packages/` vendors by digest.

The images in `cozystack-images.txt` are signed too. After the stitch, `hack/sign-release-images.sh` signs each digest with cosign, keylessly, as the `tags.yaml` run that prepared the pre-release, and verifies every signature against the same identity as above before `hack/upload-assets.sh` runs, so a release is never published with unsigned images. A signature over an index covers every manifest the index lists by digest, the attestation manifest that holds the SBOM included, which is why the SBOM carries no signature of its own. cosign stores each signature as a Sigstore bundle, an OCI referrer of the digest it signs, in the same repository. GHCR serves no referrers API, so cosign lists the referrer under the fallback tag `sha256-<hex>` of that digest, where `cosign verify` finds it with no extra flags; the tag `sha256-<hex>.sig` is the legacy format, written only with `--new-bundle-format=false`, and a release has none. Every digest gets its own short-lived key, Fulcio certificate and Rekor entry. Promotion copies each digest to its stable tag inside that repository, so a stable release's images carry the signatures made for its rc, and their certificates name `tags.yaml` at the rc tag. `promote-rc.yaml::promote` checks every signature with the rc tree's `hack/sign-release-images.sh --verify-only` before it stages the stable release, and skips the check with a notice for an rc cut from a tree that has no such script. A re-run of `prepare-release` signs only the digests that do not verify yet, so it never stacks a second signature on an image. The packages artifact and the installer chart are not signed: promotion republishes both under a new digest.

With cosign v3.1.3 or later and the assets of the release in the current directory, this checks the signature over the checksums, every downloaded asset against them, the signature of every image the release pins, and unpacks the image SBOMs:

cosign verify-blob cozystack-checksums.txt \

--bundle cozystack-checksums.txt.sigstore.json \

--certificate-identity-regexp '^https://github\.com/cozystack/cozystack/\.github/workflows/(tags\.yaml@refs/tags/v|promote-rc\.yaml@refs/heads/main$)' \

--certificate-oidc-issuer https://token.actions.githubusercontent.com &&

sha256sum --check --ignore-missing cozystack-checksums.txt &&

(

while read -r image <&3; do

cosign verify "$image" \

--certificate-identity-regexp '^https://github\.com/cozystack/cozystack/\.github/workflows/(tags\.yaml@refs/tags/v|promote-rc\.yaml@refs/heads/main$)' \

--certificate-oidc-issuer https://token.actions.githubusercontent.com >/dev/null ||

{ echo "not verified: $image" >&2; exit 1; }

done 3<cozystack-images.txt

) &&

mkdir -p image-sboms && tar -xzf cozystack-images-sbom.tar.gz -C image-sboms

The loop stops at the first image that fails, names it and fails the chain, so the SBOMs are unpacked only after every image verified; the list is read from fd 3 so that cosign cannot read it from stdin. `cosign verify` prints the certificate of each signature; its `Subject` names the workflow and the tag, and the image is pulled only as far as its manifests. The same SBOM can be read from the registry without the archive, with `docker buildx imagetools inspect <image> --format '{{ json .SBOM }}'`, which prints the documents keyed by platform. Checking an image by the tag a release page shows rather than by the digest in `cozystack-images.txt` proves less: a tag can be moved, a digest cannot, and the signature is bound to the digest.

What fails, and what it means: `cosign verify-blob` rejecting the bundle, or `cosign verify` finding no matching signature, means the file or the image is not what the release workflow published, or cosign is older than the version above; `sha256sum` reporting a mismatch means the download is corrupt or replaced; an image in `cozystack-images.txt` that `cosign verify` cannot find at all means the registry no longer serves that digest. An image missing from the archive cannot happen for a release that has one, since `hack/collect-image-sboms.sh` fails the release instead.

| `Sign the release images and collect their SBOMs` fails | `hack/sign-release-images.sh` could not sign a pinned digest or its signature does not verify against the release identity, or `hack/collect-image-sboms.sh` found a pinned image with no SBOM attestation | A signing failure names the ref: Fulcio or Rekor unreachable, or the OIDC token missing, re-run once they answer; a signature already there is kept, so a re-run signs only what is missing. An image without an SBOM was built without `SBOM=1` on the docker-container builder, or its index lost the attestation: fix the build, re-cut the rc | Yes |