Sign release binaries (Setup, packages, CLI) — needs a signing identity from the owner #57

New Issue

2026-10-09T12:14:37Z

KofTwentyTwo commented

2026-10-09 12:14:37 +00:00

(Migrated from github.com)

Problem

The release pipeline ships unsigned binaries: vpk pack runs without --signParams / --azureTrustedSignFile, and no signtool step exists, so gclo-stable-Setup.exe, the portable zip, the delta/full packages, and gclo-cli-win-x64.zip carry no Authenticode signature. Velopack verifies downloaded packages only against the SHA in releases.<channel>.json, which lives in the same GitHub release, so the trust chain for silent self-update is TLS plus the integrity of the owner's GitHub account. Users also get SmartScreen friction on every install.

Verified at the #32 review and again on 2026-10-09; the Windows UI smoke, build-provenance attestation (added on dev, .github/workflows/release.yml) and tag-on-main guard (#44) narrow the gap but do not close it: an attestation proves which workflow built the asset, not that the publisher is who they say they are.

What is needed from the owner

This cannot be done from inside the repo — it needs a signing identity:

Choose a signing path: Azure Trusted Signing (recommended: pay-as-you-go, no hardware token, Velopack supports it natively via --azureTrustedSignFile), or an OV/EV code-signing certificate.
Add the credentials as repository secrets (for Trusted Signing: AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET or federated OIDC, plus the endpoint/account/profile names in a committed signing.json).
Decide whether signing should be a hard gate (release fails without it) or best-effort while the identity is being set up.

Once the identity exists (engineering, not owner work)

Sign the CLI exe before zipping and pass the sign parameters to vpk pack so Setup, the portable build, and every package are signed.
Add a verification step (signtool verify /pa) on the produced assets.
Update docs/RELEASING.md and SECURITY.md (the "how updates are trusted" story).

Related: #32 (source finding), #44 (release gates), #7 (owner checklist).

## Problem The release pipeline ships unsigned binaries: `vpk pack` runs without `--signParams` / `--azureTrustedSignFile`, and no signtool step exists, so `gclo-stable-Setup.exe`, the portable zip, the delta/full packages, and `gclo-cli-win-x64.zip` carry no Authenticode signature. Velopack verifies downloaded packages only against the SHA in `releases.<channel>.json`, which lives in the same GitHub release, so the trust chain for silent self-update is TLS plus the integrity of the owner's GitHub account. Users also get SmartScreen friction on every install. Verified at the #32 review and again on 2026-10-09; the Windows UI smoke, build-provenance attestation (added on `dev`, `.github/workflows/release.yml`) and tag-on-main guard (#44) narrow the gap but do not close it: an attestation proves which workflow built the asset, not that the publisher is who they say they are. ## What is needed from the owner This cannot be done from inside the repo — it needs a signing identity: - [ ] Choose a signing path: **Azure Trusted Signing** (recommended: pay-as-you-go, no hardware token, Velopack supports it natively via `--azureTrustedSignFile`), or an OV/EV code-signing certificate. - [ ] Add the credentials as repository secrets (for Trusted Signing: `AZURE_TENANT_ID`, `AZURE_CLIENT_ID`, `AZURE_CLIENT_SECRET` or federated OIDC, plus the endpoint/account/profile names in a committed `signing.json`). - [ ] Decide whether signing should be a hard gate (release fails without it) or best-effort while the identity is being set up. ## Once the identity exists (engineering, not owner work) - Sign the CLI exe before zipping and pass the sign parameters to `vpk pack` so Setup, the portable build, and every package are signed. - Add a verification step (`signtool verify /pa`) on the produced assets. - Update `docs/RELEASING.md` and `SECURITY.md` (the "how updates are trusted" story). Related: #32 (source finding), #44 (release gates), #7 (owner checklist).

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: KofTwentyTwo/gclo#57