Record the pending GitHub GC request in the exposure ledger - #128
Merged
Conversation
The 2026-08-19 history rewrite (021d2b6) is recorded here as "purged from history", which is true of every reachable commit but not of what GitHub still serves. Verified 2026-08-26: 647d90a, 21afcad, efb2632 and ee3d443 all still resolve through the API, and the tree at 21afcad still lists the two private keys. That is the purge runbook's "Afterwards" step — ask Support to run GC — and it was the last one outstanding with no written trace. Requested 2026-08-26; this row is where its state lives until it lands. Written as an exposure row rather than a task, because the gap was in the record: the existing rows imply the objects are gone. It says explicitly that credential status is unchanged, since rotation preceded the rewrite, so a pending GC is not mistaken later for an unremediated leak. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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
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.
One row added to the Known exposure table in
SECURITY.md.The gap
The ledger currently says the SNMP community and the TLS private keys were
"purged from git history". That is true of every reachable commit — the
2026-08-19 rewrite (
021d2b6) did its job, and.git/filter-repo/already_ranplus the absence of the old SHAs locally both confirm it.
It is not true of what GitHub still serves. Verified 2026-08-26:
647d90acertificates/21afcadefb2632certificates/was addedee3d443certificates/Gandalf.Gondor.Lab/ca-key.pemandcert-key.pemremain listed inthe tree at
21afcad, on a public repository. (Tree metadata only — key contentswere not fetched.)
Why a row and not a checklist tick
docs/runbooks/purge-git-history.mdanticipates this exactly — its Afterwardssection says to ask GitHub Support to run GC, and notes forks would make it
unfixable. That step was the last one outstanding and had no written trace
anywhere. But the reason it belongs in the ledger rather than a TODO is that the
existing rows imply the objects are gone, and they aren't. That's a gap in
the record, not just an unticked box.
What it does and doesn't claim
lives until it lands.
the objects.
the CA was regenerated. The row says so explicitly, so a pending GC is not
misread later as an unremediated leak. The old community remains, per the
existing row, something that "must still be treated as public."
gh api repos/Gerrrt/HomeLab/commits/647d90a --jq .sha— a404means done.Follow-up
This row has a live date on it. Once GitHub collects the objects it wants
flipping from pending to collected, and at that point the two older rows
become fully accurate as written.
🤖 Generated with Claude Code