Skip to main content

Secure updates

How Roasthubs edge software is updated today, and what still has to change for CRA Annex I Part II §§7–8. Operational detail: rhsos-infra/docs/secure-update-policy.md. This page is not a signed Annex II “how to apply updates” leaflet.

How updates work today​

  1. Application images live in AWS ECR (eu-west-1, repository roasthubs-os).
  2. The edge host authenticates with a short-lived ECR token (max 24 hours).
  3. deploy.sh backs up the database to S3, compares the running image digest to the remote digest for tag {staging-}latest, verifies the Cosign signature of that digest, and on mismatch pulls that floating tag, recreates the roasthubs container, records version and digest, and restarts the stack.
  4. Compose does not pin immutable digests. The digest check only decides whether to pull :latest.
  5. Images pushed to ECR by GitHub Actions are Cosign keyless-signed. Unsigned remotes are refused unless ALLOW_UNSIGNED_IMAGE=1.
  6. There is no automated rollback. Recovery is a previous ECR digest/tag plus S3 database restore if needed.

CRA expectations (plain language)​

ThemeExpectation
Part II §7Identify, assess, and remediate vulnerabilities; distribute updates securely.
Part II §8Security updates during a defined support period; security fixes without additional charge in that window; timely delivery and user communication; separate from feature updates where possible.

Gaps (6 Oct 2026)​

  • Pin image digests in compose/deploy (digest compare still gates whether to pull a floating tag).
  • Cut over the first Cosign-signed image on hosts (ALLOW_UNSIGNED_IMAGE=1 only for images published before signing).
  • Separate security releases from feature releases (advisories process exists; see security advisories).
  • Documented rollback to a previous digest.
  • Published support-period end date (still draft).

Report vulnerabilities: vulnerability disclosure. Advisories: security advisories.