Skip to content

Record the pending GitHub GC request in the exposure ledger - #128

Merged
Gerrrt merged 1 commit into
mainfrom
security/record-pending-gc-request
Aug 26, 2026
Merged

Record the pending GitHub GC request in the exposure ledger#128
Gerrrt merged 1 commit into
mainfrom
security/record-pending-gc-request

Conversation

@Gerrrt

@Gerrrt Gerrrt commented Aug 26, 2026

Copy link
Copy Markdown
Owner

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_ran
plus the absence of the old SHAs locally both confirm it.

It is not true of what GitHub still serves. Verified 2026-08-26:

SHA Still resolves via API
647d90a the commit that deleted certificates/
21afcad its parent — tree here still lists the private keys
efb2632 where certificates/ was added
ee3d443 where the SNMP community was committed

certificates/Gandalf.Gondor.Lab/ca-key.pem and cert-key.pem remain listed in
the tree at 21afcad, on a public repository. (Tree metadata only — key contents
were not fetched.)

Why a row and not a checklist tick

docs/runbooks/purge-git-history.md anticipates this exactly — its Afterwards
section 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

  • GC requested from Support 2026-08-26 — pending. The row is where that state
    lives until it lands.
  • Repository has 0 forks, network count 0, so nothing else is perpetuating
    the objects.
  • Credential status is unchanged. Both were rotated before the rewrite, and
    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."
  • Carries the re-check command so verification needs no re-deriving:
    gh api repos/Gerrrt/HomeLab/commits/647d90a --jq .sha — a 404 means 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

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>
@Gerrrt
Gerrrt merged commit a2efacb into main Aug 26, 2026
3 checks passed
@Gerrrt
Gerrrt deleted the security/record-pending-gc-request branch August 26, 2026 04:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant