docs(token-rotation): one token in five places, expiring 2027-06-29 - #87
Merged
Merged
Conversation
The table I filled in last commit implied five independently minted tokens with five unknown expiries. There is one token, minted 2026-06-29 and expiring 2027-06-29, copied into five locations -- the migration reused the existing credential rather than minting new ones, to avoid adding a variable mid-migration. That distinction is the whole point of the doc: a rotation has to update every location, and a reader who thinks these are separate credentials will rotate one and leave four live on an expiring token. Step 2 of the runbook now says so. The dates from `gh secret list` are when each copy was written, not when the token was minted. Renamed that column to "Secret last set" so it cannot be read as a rotation input. photo-game-poc is the exception: its copy predates 2026-06-29, so it holds an older token whose expiry is unrecorded. Marked unknown rather than assumed. The repo is archived and runs nothing, so it is not urgent -- re-setting the secret from the current token folds it in. Calendar reminder set for 2027-06-15, two weeks before expiry, naming all five locations. Claude-Session: https://claude.ai/code/session_01MM2jf6c7eNN4QMq32GdC5X
Closed
4 tasks
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.
Corrects the table from #86, which implied five independently minted tokens
with five unknown expiries.
There is one token: minted 2026-06-29, expiring 2027-06-29, copied
into five locations. The migration reused the existing credential rather
than minting new ones, deliberately, to avoid adding a variable mid-flight.
Why this matters
It is the doc's whole purpose. A reader who thinks these are separate
credentials rotates one and leaves four live on an expiring token. Step 2
of the runbook now says explicitly to update every location.
Also renamed the
Mintedcolumn toSecret last set— those dates aregh secret list'supdated_at, which is when each copy was written, notwhen the token was minted. As a column called "Minted" it was an invitation
to compute the wrong expiry.
One row is genuinely unknown
photo-game-poc's copy was written 2026-03-02, months before 2026-06-29,so it holds an older token whose expiry is recorded nowhere. Marked unknown
rather than assumed. The repo is archived and runs nothing, so it is not
urgent — re-setting that secret from the current token folds it into the
block above.
Calendar
Reminder created for 2027-06-15 (two weeks before expiry), naming all five
locations, with the runbook link and the "read the log, a green check is
not evidence" warning. Email a week out, popup the day before.
Verification
created_at/updated_atpulled for all five secrets — that is whatsurfaced the photo-game-poc discrepancy
Splitting these into per-scope tokens is deferred, by your call.
https://claude.ai/code/session_01MM2jf6c7eNN4QMq32GdC5X