unom/punktfunk
6
0
Fork 1
Code Issues 4 Pull Requests Actions 1 Packages Projects Releases 50 Wiki Activity

Remove the legacy-identity fallback on 2026-10-01 (published deprecation in the v0.28.0 notes) #201

New Issue
Open
opened 2026-08-13 15:55:19 +00:00 by enricobuehler · 0 comments
enricobuehler commented 2026-08-13 15:55:19 +00:00
Owner
Copy Link
Copy Source

Why this issue exists

The v0.28.0 release notes publish a date: "From 1 October 2026 the host will stop falling back to the old identity." Nothing in the tree removes that fallback today, so without a tracked change the notes will have promised something that silently never happens — the same shape as the v0.22.3 notes describing a feature that release never contained.

This issue is that tracked change.

What to remove

crates/punktfunk-host/src/identity.rs — load_or_adopt(). The migration rule has three arms:

  1. native-cert.pem + native-key.pem exist → use them (steady state) — keep
  2. native trust store empty → generate P-256, persist, adopt — keep
  3. upgraded host with live native pairings → keep presenting the legacy RSA cert.pem/key.pem those clients pinned (identity.rs ~L79–94, the arm that logs "native identity: keeping the legacy RSA cert…") — this is the arm to delete

After removal, arm 3 collapses into the existing degenerate path just below it (~L95–105): mint the P-256 identity and warn that those clients must re-pair.

Scope — read this before widening it

⚠ The GameStream/Moonlight plane is NOT part of this deprecation and keeps its RSA identity permanently. Moonlight mandates RSA and its pairing hashes bind the certificate's X.509 signature bytes, so that identity cannot move without breaking every Moonlight client forever. Only the native punktfunk/1 plane + management API fallback is dated.

Also unaffected:

  • Fresh installs since v0.28.0 — already on ECDSA P-256.
  • Operators who migrate early. No release is needed for that: unpair all native clients → restart the host → re-pair. The host already logs exactly this.

Blast radius when the arm goes

Removing it means an un-migrated host mints a new identity, so its native clients' pinned fingerprints stop matching and they must re-pair once. Consumers that follow the identity and should be re-checked:

  • crates/punktfunk-tray/src/status.rs — loopback pin reads native-cert.pem
  • crates/punktfunk-host/src/plugins.rs — RUNNER_SECRET_FILES includes both native-cert.pem and cert.pem
  • sdk/src/config.ts — mgmt CA resolution falls back native-cert.pem → cert.pem

The cert.pem fallbacks in those three are for N-1 hosts, not for this arm, so they likely stay. Confirm rather than assume.

Tests that pin the current behaviour

In identity.rs:

  • keeps_legacy_rsa_while_native_pairings_exist() — this one inverts: after the change it should assert the P-256 identity is minted instead.
  • adopts_p256_when_no_client_ever_pinned() — unchanged.
  • mints_p256_when_legacy_files_vanished() — unchanged (becomes the only minting path for a paired host).

Definition of done

  • Arm 3 deleted; keeps_legacy_rsa_while_native_pairings_exist inverted and renamed
  • The three identity-following consumers above re-checked
  • rsa stays absent from the native-only build (cargo tree -i rsa --no-default-features --features pyrowave finds nothing)
  • Release notes for the version that ships it state plainly that un-migrated hosts re-pair once
  • CHANGELOG's 🗓 Deprecation subsection under The identity split (v0.28.0) updated to point at the release that executed it

References

  • v0.28.0 CHANGELOG.md → The identity split — the native planes get their own (P-256) host identity → 🗓 Deprecation: the legacy-identity fallback goes away on 1 October 2026
  • v0.28.0 docs/releases/v0.28.0.md → Before you update, and the ## For developers section

ℹ️ Note for whoever picks this up: the identity is ECDSA P-256, not Ed25519 — deliberately, because no mainstream browser accepts an Ed25519 server certificate and operators open /api/docs in one.

## Why this issue exists The v0.28.0 release notes **publish a date**: *"From 1 October 2026 the host will stop falling back to the old identity."* Nothing in the tree removes that fallback today, so without a tracked change the notes will have promised something that silently never happens — the same shape as the v0.22.3 notes describing a feature that release never contained. This issue is that tracked change. ## What to remove `crates/punktfunk-host/src/identity.rs` — `load_or_adopt()`. The migration rule has three arms: 1. `native-cert.pem` + `native-key.pem` exist → use them (steady state) — **keep** 2. native trust store empty → generate P-256, persist, adopt — **keep** 3. **upgraded host with live native pairings → keep presenting the legacy RSA `cert.pem`/`key.pem` those clients pinned** (identity.rs ~L79–94, the arm that logs *"native identity: keeping the legacy RSA cert…"*) — **this is the arm to delete** After removal, arm 3 collapses into the existing degenerate path just below it (~L95–105): mint the P-256 identity and warn that those clients must re-pair. ## Scope — read this before widening it ⚠ **The GameStream/Moonlight plane is NOT part of this deprecation and keeps its RSA identity permanently.** Moonlight mandates RSA and its pairing hashes bind the certificate's X.509 signature bytes, so that identity cannot move without breaking every Moonlight client forever. Only the **native punktfunk/1 plane + management API** fallback is dated. Also unaffected: - Fresh installs since v0.28.0 — already on ECDSA P-256. - Operators who migrate early. No release is needed for that: *unpair all native clients → restart the host → re-pair*. The host already logs exactly this. ## Blast radius when the arm goes Removing it means an un-migrated host mints a new identity, so **its native clients' pinned fingerprints stop matching and they must re-pair once**. Consumers that follow the identity and should be re-checked: - `crates/punktfunk-tray/src/status.rs` — loopback pin reads `native-cert.pem` - `crates/punktfunk-host/src/plugins.rs` — `RUNNER_SECRET_FILES` includes both `native-cert.pem` and `cert.pem` - `sdk/src/config.ts` — mgmt CA resolution falls back `native-cert.pem` → `cert.pem` The `cert.pem` fallbacks in those three are for **N-1 hosts**, not for this arm, so they likely stay. Confirm rather than assume. ## Tests that pin the current behaviour In `identity.rs`: - `keeps_legacy_rsa_while_native_pairings_exist()` — **this one inverts**: after the change it should assert the P-256 identity is minted instead. - `adopts_p256_when_no_client_ever_pinned()` — unchanged. - `mints_p256_when_legacy_files_vanished()` — unchanged (becomes the only minting path for a paired host). ## Definition of done - [ ] Arm 3 deleted; `keeps_legacy_rsa_while_native_pairings_exist` inverted and renamed - [ ] The three identity-following consumers above re-checked - [ ] `rsa` stays absent from the native-only build (`cargo tree -i rsa --no-default-features --features pyrowave` finds nothing) - [ ] Release notes for the version that ships it state plainly that un-migrated hosts re-pair once - [ ] CHANGELOG's `🗓 Deprecation` subsection under **The identity split** (v0.28.0) updated to point at the release that executed it ## References - v0.28.0 `CHANGELOG.md` → *The identity split — the native planes get their own (P-256) host identity* → `🗓 Deprecation: the legacy-identity fallback goes away on 1 October 2026` - v0.28.0 `docs/releases/v0.28.0.md` → **Before you update**, and the `## For developers` section ℹ️ Note for whoever picks this up: the identity is **ECDSA P-256, not Ed25519** — deliberately, because no mainstream browser accepts an Ed25519 server certificate and operators open `/api/docs` in one.
enricobuehler added the due date 2026-10-01 2026-08-13 15:55:26 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
FernandoMX enricobuehler (Enrico Bühler) kszlim nannku neoney sassycrown
No Assignees
1 Participants
Notifications
Due Date
2026-10-01
Dependencies

No dependencies set.

Reference: unom/punktfunk#201