fix: keep the registered identity stable and stop init destroying keys - #8
Merged
Conversation
Verifier registration records a keyid and a User-Agent that a human reviews, so anything that changes either one silently invalidates a registration that took days to obtain. Three ways that could happen: - `wingfoot init` overwrote an existing identity with no check or prompt. It reads like a safe command to re-run, but it generates a new key and so a new keyid. Now refuses unless --force, and points at the non-destructive path. - `register --user-agent` only affected the printed form; outbound requests still carried the default. A custom UA therefore registered a bot that never appears in the verifier's logs. The identity now records the UA and signed_headers applies it, so requests/httpx/manual clients all send what register declares. - The default User-Agent embedded the release version, so shipping a patch stopped it matching the registered string. It is now unversioned; the repo URL is what identifies us. Adds `wingfoot identity` to show the identity and change its agent URL or User-Agent in place, which is the only safe way to correct those fields once a key is registered. Identities stored before the UA field remain loadable and are not given one implicitly.
These are internal marketing notes — a prepared Show HN comment, channel strategy, and registration packets containing a contact email. They were never meant to ship in a public repo. Kept on disk, ignored from here on.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Verifier registration records a
keyidand a User-Agent that a human reviews. Anything that changes either one silently invalidates a registration that took days to obtain. Three ways that could happen, found while preparing an actual registration:1.
wingfoot initdestroyed an existing identity, silentlyNo check, no prompt — it generated a fresh keypair and overwrote
private_key.pem. It reads like a command that is safe to re-run. The day after a verifier approves you, re-running it throws away the registration.Now refuses unless
--force, and the error names the consequence and points at the non-destructive alternative.2.
register --user-agentdeclared a UA that was never sentThe flag only changed the printed form; outbound requests still carried the default. Anyone declaring a custom UA registered a bot that never appears in the verifier's logs. The same gap affected
requests_auth()/httpx_auth(), which let the client send its ownpython-requests/2.x.The identity now records the UA and
signed_headers()applies it — one chokepoint, so every client path sends whatregisterdeclares.3. The default User-Agent embedded the release version
wingfoot/0.1.2 (+...)stopped matching the registered string on the next patch release. Now unversioned; the repo URL is the identifying part. A test fails if a version ever reappears in it.New:
wingfoot identityShows the identity, and
--agent/--user-agentchange those fields in place without touching the key — the only safe way to correct them once a key is registered. No such path existed before.Compatibility
Identities stored before the UA field remain loadable and are not given one implicitly, so existing setups keep their current behaviour and their keyid.
Verification
58 tests pass (5 new). Verified against a real registered identity:
initrefused and left the key intact,identity --user-agentupdated the config with the keyid unchanged, anddemo/doctorstill behave as before.