Status: shelf / someday-maybe. Parked idea, not committed work. Filed so it isn't lost.
The itch
Release tags are GPG-signed (convention since ways-v0.8.0), but signing needs an interactive pinentry passphrase on the local machine's display — and the key is on a YubiKey requiring a physical touch. When the operator drives a session remotely, neither is reachable, so the tag can't be signed in-session. ways-v0.9.0 shipped unsigned for exactly this reason (signed 0.9.1 re-tag planned from a local session).
Goal: cut a signed release tag from a remote session without breaking the YubiKey trust model — or consciously decide the trade is worth a different model.
Options on the table (sketch, with trade-offs)
- Passphrase in an
.env (rejected as-is — security smell). Storing the signing-key passphrase in plaintext defeats the point, and it still doesn't solve the YubiKey touch requirement. The secrets way would side-eye this.
- Remote-trigger → local YubiKey touch (the "drinky-bird" idea). A
RemoteTrigger-style surface that pokes the always-on local box to perform the touch/sign on demand. Needs the local machine online + a trigger endpoint + agent reachability. Most faithful to the hardware-key model; most moving parts.
- gpg-agent / ssh forwarding to the local machine, so the remote session signs through the local agent. Standard pattern; needs the forward wired up and the local box awake.
- Sign in CI with a key in Actions secrets. Releases are already CI-driven (
build-ways.yml); the workflow could sign the tag (or just the checksums/binaries) with a dedicated key in GitHub secrets. No local presence needed — but it moves signing trust off the YubiKey into CI, a different (weaker for tags, fine for artifact-attestation) model. Possibly the pragmatic answer: keep the YubiKey for human-authored tags, add CI artifact signing/attestation for releases.
Adjacent papercut
Even locally, signing prompts for the passphrase every tag. The right fix is gpg-agent passphrase caching (cache-ttl), not stripping the key password. Worth wiring up regardless of which option above (if any) lands.
Decision posture
No urgency. Most likely real candidates are (4) for hands-off release artifact signing and (2/3) if remote tag signing specifically matters. Revisit when remote releases become routine rather than occasional.
Status: shelf / someday-maybe. Parked idea, not committed work. Filed so it isn't lost.
The itch
Release tags are GPG-signed (convention since
ways-v0.8.0), but signing needs an interactive pinentry passphrase on the local machine's display — and the key is on a YubiKey requiring a physical touch. When the operator drives a session remotely, neither is reachable, so the tag can't be signed in-session.ways-v0.9.0shipped unsigned for exactly this reason (signed0.9.1re-tag planned from a local session).Goal: cut a signed release tag from a remote session without breaking the YubiKey trust model — or consciously decide the trade is worth a different model.
Options on the table (sketch, with trade-offs)
.env(rejected as-is — security smell). Storing the signing-key passphrase in plaintext defeats the point, and it still doesn't solve the YubiKey touch requirement. The secrets way would side-eye this.RemoteTrigger-style surface that pokes the always-on local box to perform the touch/sign on demand. Needs the local machine online + a trigger endpoint + agent reachability. Most faithful to the hardware-key model; most moving parts.build-ways.yml); the workflow could sign the tag (or just the checksums/binaries) with a dedicated key in GitHub secrets. No local presence needed — but it moves signing trust off the YubiKey into CI, a different (weaker for tags, fine for artifact-attestation) model. Possibly the pragmatic answer: keep the YubiKey for human-authored tags, add CI artifact signing/attestation for releases.Adjacent papercut
Even locally, signing prompts for the passphrase every tag. The right fix is gpg-agent passphrase caching (cache-ttl), not stripping the key password. Worth wiring up regardless of which option above (if any) lands.
Decision posture
No urgency. Most likely real candidates are (4) for hands-off release artifact signing and (2/3) if remote tag signing specifically matters. Revisit when remote releases become routine rather than occasional.