Skip to content

Serve signed desktop stable/beta/nightly channel manifests with rollback protection #97

Description

@ORESoftware

Goal

Serve canonical mutable desktop release-channel pointers from Cloudflare using DesktopReleaseChannelManifestV1, while keeping installer bytes immutable/content-addressed and enforcing signature + generation/rollback policy at the edge/client boundary.

Depends on:

  • zed-pkg/zed-interfaces#158 — immutable desktop artifact;
  • zed-pkg/zed-interfaces#160 — signed channel manifest;
  • zed-pkg/zed-infra#96 — immutable cdn.zpkg.net/apps/artifacts/... objects.

Canonical routes

Provide stable machine-readable channel routes such as:

  • /apps/<org>/<app>/stable/manifest.json
  • /apps/<org>/<app>/beta/manifest.json
  • /apps/<org>/<app>/nightly/manifest.json

Optionally provide a convenience platform route that selects a target from the same verified manifest, but the manifest remains the explicit machine contract.

Promotion model

  • immutable artifact must already exist and pass certification before promotion;
  • promoter writes a new signed manifest generation, never mutates installer bytes;
  • promotion authority is separate from artifact upload authority;
  • generation must advance monotonically under the selected application/channel authority;
  • exact replay of the current generation is idempotent;
  • lower/stale generation is rejected/quarantined;
  • conflicting same-generation payload is a hard failure;
  • rollback, when intentionally required, needs an explicit audited mechanism that creates a new generation pointing at an older immutable artifact rather than replaying stale signed state.

Verification / caching

  • verify signature/key id/audience/application/channel before serving/promoting as authoritative;
  • cache manifest only for a short bounded interval appropriate to mutable pointer data;
  • expose ETag/generation and conditional GET;
  • do not cache invalid signature or parse failures as a valid manifest;
  • installer target URLs must resolve only to #96 content-addressed objects;
  • unknown/unsupported target platform returns an explicit typed miss, not a guessed artifact.

Key rotation

Use a bounded public verification-key lifecycle with overlap/revocation semantics. Do not reuse a high-authority package/auth signing key automatically; desktop promotion keys should have a narrow audience/purpose.

Tests

  • valid stable manifest -> exact immutable artifact target;
  • beta/nightly independent generations;
  • invalid signature/unknown key;
  • stale generation rollback refusal;
  • conflicting same generation;
  • manifest references missing artifact;
  • manifest target digest/path mismatch;
  • key rotation overlap and revocation;
  • cache/ETag/304 behavior;
  • intentional rollback via new higher generation;
  • upload principal cannot promote channel and promoter cannot replace immutable bytes.

Evidence

Retain signed manifest digest, generation, key id, referenced artifact digests, exact Worker revision, and promotion operation id without signing private material.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions