P0-5: Generate the EdDSA update-signing key #20

New issue

Open

opened 2026-09-10 17:40:26 +00:00 by Cordy · 0 comments

Cordy commented

2026-09-10 17:40:26 +00:00

Owner

Manual task. Depends on P0-1. Prerequisite for P3-7 (auto-update).

Scope corrected 2026-09-10. This issue originally also covered the Google Play account
and the mobile repos' licences. Those are mobile concerns and have moved to the repos they
belong to: Cordy/cairn-android issue #2 and Cordy/cairn-ios issue #2. This issue now
covers only the desktop update-signing key.

Generate the EdDSA update-signing key

Auto-update (P3-7) verifies downloads with an EdDSA/Ed25519 signature that is independent of
TLS, so a compromised web server cannot push a malicious build. Sparkle (macOS) and
WinSparkle (Windows) use the same key format and tooling, so one key serves both
platforms.

Mobile does not need this — app stores handle update integrity themselves. This is desktop-only.

Generate the key pair using Sparkle's generate_keys or winsparkle-tool.
Store the private key offline — a password manager entry or hardware token. Not the
repo, not CI, not the web server.
Record the public key; it gets embedded in the client at build time.
Document where the private key lives, so a future you can find it. A signing key nobody
can locate is the same as a lost one.

Why it must be separate from the code-signing certificate

Two different compromises, two different keys:

The code-signing certificate (P0-2 for Apple, P0-3 for Windows) proves who built the
binary.
The EdDSA key proves this specific artifact is the one you published.

If both live in the same place, compromising the website becomes sufficient to ship signed
malware to every installed client. Keeping them separate means an attacker needs the update
key and the code-signing identity. This is the whole reason the update mechanism does not
simply trust TLS.

Acceptance criteria

EdDSA key pair generated.
Private key stored offline, in a location recorded somewhere durable.
Public key recorded for embedding in P3-7.
The key is not in the repo, in CI, or on the web server.

**Manual task.** Depends on P0-1. Prerequisite for P3-7 (auto-update). > **Scope corrected 2026-09-10.** This issue originally also covered the Google Play account > and the mobile repos' licences. Those are mobile concerns and have moved to the repos they > belong to: `Cordy/cairn-android` issue #2 and `Cordy/cairn-ios` issue #2. This issue now > covers only the desktop update-signing key. ## Generate the EdDSA update-signing key Auto-update (P3-7) verifies downloads with an **EdDSA/Ed25519 signature that is independent of TLS**, so a compromised web server cannot push a malicious build. Sparkle (macOS) and WinSparkle (Windows) use the **same** key format and tooling, so **one key serves both platforms**. Mobile does not need this — app stores handle update integrity themselves. This is desktop-only. - [ ] Generate the key pair using Sparkle's `generate_keys` or `winsparkle-tool`. - [ ] **Store the private key offline** — a password manager entry or hardware token. Not the repo, not CI, not the web server. - [ ] Record the public key; it gets embedded in the client at build time. - [ ] Document where the private key lives, so a future you can find it. A signing key nobody can locate is the same as a lost one. ## Why it must be separate from the code-signing certificate Two different compromises, two different keys: - The **code-signing certificate** (P0-2 for Apple, P0-3 for Windows) proves who built the binary. - The **EdDSA key** proves this specific artifact is the one you published. If both live in the same place, compromising the website becomes sufficient to ship signed malware to every installed client. Keeping them separate means an attacker needs the update key *and* the code-signing identity. This is the whole reason the update mechanism does not simply trust TLS. ## Acceptance criteria - EdDSA key pair generated. - Private key stored offline, in a location recorded somewhere durable. - Public key recorded for embedding in P3-7. - The key is **not** in the repo, in CI, or on the web server.