diff --git a/.github/workflows/colony-rust-release.yml.template b/.github/workflows/colony-rust-release.yml.template deleted file mode 100644 index d2e4842..0000000 --- a/.github/workflows/colony-rust-release.yml.template +++ /dev/null @@ -1,38 +0,0 @@ -# Colony Rust program — release workflow -# -# ┌─────────────────────────────────────────────────────────────────────────┐ -# │ THIS FILE IS NOT THE TEMPLATE. The canonical one lives in │ -# │ │ -# │ Project-Colony-Resources / templates/release.yml │ -# │ https://github.com/Project-Colony/Project-Colony-Resources │ -# │ │ -# │ Copy THAT file to your repo as .github/workflows/release.yml. │ -# └─────────────────────────────────────────────────────────────────────────┘ -# -# Why this is a pointer and not a copy: it used to be a copy, and the two -# drifted. The Resources template referenced a secret named -# COLONY_SIGNING_KEY while every real repo uses COLONY_SIGNING_KEY_PEM, and it -# skipped signing on Windows entirely - so a program following it shipped an -# unsigned .exe that Colony then refused to install, because the manifest said -# "signed": true. Neither mistake was visible from either side. One canonical -# file, kept next to the shared script it calls, is what stops that recurring. -# -# What you need, in short: -# -# 1. colony.json at your repo root (name + category is usually the whole -# file). Validate it with: colony validate-manifest colony.json -# 2. templates/release.yml -> .github/workflows/release.yml -# 3. templates/sign-release.sh -> scripts/sign-release.sh (only if you set -# "signed": true; the workflow calls it from there) -# 4. The COLONY_SIGNING_KEY_PEM organisation secret, which is restricted to -# Project-Colony repositories. -# -# The full contract - asset naming, the manifest, signing, the .meta sidecar, -# key rotation, and how to adopt signatures in a program that already ships - -# is in Project-Colony-Resources / design/releases.md. -# -# Colony's own release pipeline (.github/workflows/release-please.yml) signs and -# publishes through the shared workflow in Project-Colony-Resources, -# .github/workflows/sign-and-publish.yml (caller example: -# templates/sign-and-publish-caller.yml). Colony self-updates, so for it the -# signatures are mandatory rather than opt-in. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 877222f..a5f3595 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -46,9 +46,9 @@ You can upload any subset — Colony only advertises the platforms whose asset i ### Step 3 — Wire up a release workflow (Rust apps) -The ready-to-use GitHub Actions template lives in Project-Colony-Resources at [`templates/release.yml`](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/release.yml), next to the shared signing script it calls. Copy it to your own repo as `.github/workflows/release.yml` and replace `{{APP_NAME}}` with your binary/repo name (lowercase). +The ready-to-use GitHub Actions template lives in Project-Colony-Resources at [`templates/sign-and-publish-caller.yml`](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/sign-and-publish-caller.yml). Copy it to your own repo as `.github/workflows/release.yml` and replace `{{APP_NAME}}` with your binary/repo name (lowercase). Its build jobs never see a signing key: signing and publishing happen in the organisation's [shared signing workflow](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/design/releases.md#shared-signing-workflow), which the template calls. -It uses [`release-please`](https://github.com/googleapis/release-please) so every merged PR tagged with a conventional-commit prefix (`feat:`, `fix:`, etc.) opens a release PR; merging that PR tags the version, builds the matrix of 4 platforms, and uploads the assets under the convention above. Zero manual release work afterwards. +It uses [`release-please`](https://github.com/googleapis/release-please) so every merged PR tagged with a conventional-commit prefix (`feat:`, `fix:`, etc.) opens a release PR; merging that PR tags the version, builds the matrix of 4 platforms, then signs and publishes the assets under the convention above. Zero manual release work afterwards. Non-Rust apps: replicate the same asset naming convention with whatever tooling you prefer (electron-builder, pyinstaller, go build, etc.). diff --git a/README.md b/README.md index 2afbba4..eb7a388 100644 --- a/README.md +++ b/README.md @@ -111,7 +111,7 @@ Then publish a GitHub Release with assets named `yourapp-linux`, `yourapp-window **Full walkthrough**: see [CONTRIBUTING.md § Adding your app to Colony](CONTRIBUTING.md#adding-your-app-to-colony). -The canonical [release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/release.yml) lives in Project-Colony-Resources, alongside the shared signing script and the manifest schema. +The canonical [release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/sign-and-publish-caller.yml) lives in Project-Colony-Resources, alongside the shared signing workflow it calls and the manifest schema. ## Platforms diff --git a/docs/colony-spec.md b/docs/colony-spec.md index 6ec29c9..41697bd 100644 --- a/docs/colony-spec.md +++ b/docs/colony-spec.md @@ -224,17 +224,12 @@ signing is adopted per-app, no flag day - **unless** the manifest declares: With `"signed": true`, a missing signature ABORTS the install. Declare it once every release of the app ships `.sig` assets. Not every Project-Colony app signs its releases yet, so check an app's release assets rather than assuming. -Sign with: - -```sh -COLONY_SIGNING_KEY=/path/to/colony-release.pem \ -COLONY_RELEASE_VERSION= ./scripts/sign-release.sh -``` - -`COLONY_RELEASE_VERSION` is required because the script also emits a signed -`.meta` sidecar binding the bytes to a version and a filename. The -launcher's self-update requires it, and app installs check it whenever it is -published (see below). +An app signs nothing itself: its release workflow, copied from the +[release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/sign-and-publish-caller.yml), +hands the built binaries to the organisation's shared signing workflow. That +workflow writes `.sig` and a signed `.meta` sidecar binding the +bytes to a version and a filename. The launcher's self-update requires the +sidecar, and app installs check it whenever it is published (see below). Note the trust boundary. Signatures protect against tampered release assets (e.g. an asset swapped after publication), because forging one requires the @@ -274,5 +269,6 @@ colony validate-manifest colony.json $(tr '\n' ' ' < names.txt) ``` It exits non-zero on any problem, so it works as a CI gate. The shipped -[release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/release.yml) -already runs it against each release before signing. +[release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/sign-and-publish-caller.yml) +already runs it on every release, in its Linux build job, before anything is +signed. diff --git a/docs/docs.md b/docs/docs.md index c685230..6ced0c8 100644 --- a/docs/docs.md +++ b/docs/docs.md @@ -16,4 +16,4 @@ This folder contains the technical and end-user documentation for Colony. - [Project-Colony GitHub organization](https://github.com/Project-Colony) - [Contributing guide](../CONTRIBUTING.md) — adding your app + contributing to Colony itself -- [Release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/release.yml) and the shared signing script, in Project-Colony-Resources +- [Release workflow template](https://github.com/Project-Colony/Project-Colony-Resources/blob/main/templates/sign-and-publish-caller.yml) and the shared signing workflow it calls, in Project-Colony-Resources