security: tighten gitleaks regex + document history-purge audit trail #14
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: d-bis/explorer-monorepo#14
Reference in New Issue
Block a user
Summary
Two small follow-ups to the out-of-band git-history rewrite that purged
L@ker$2010/L@kers2010/L@ker\$2010from every branch and tag in this repository today.Changes
.gitleaks.tomlRegex was
L@kers?\$?2010, which catches the expanded form but NOT the shell-escaped form (L@ker\$2010) that slipped past PR #3 inscripts/setup-database.sh. PR #13 fixed the live leak but didn't tighten the detector. New regexL@kers?\\?\$?2010catches both forms so future pastes of either form fail CI.Description rewritten without literal passwords (the previous description was redacted by the history rewrite itself and read
Legacy hardcoded ... (***REDACTED-LEGACY-PW*** / ***REDACTED-LEGACY-PW***), which was cryptic).docs/SECURITY.mdrefs/pull/*/headrefs (read-only PR head mirrors) cannot be force-updated over HTTPS — the server'supdatehook declines them. Gives the explicitgit update-ref -d+git gc --prune=nowrecipe for the gitea user on the VM.78e1ff5.History-purge summary (out-of-band)
Ran
git clone --mirror → git filter-repo --replace-text → git filter-repo --replace-message → git push --mirror --force. Result:mastertree matchesscripts/setup-database.sh(escaped form)L@kers?\$?2010L@ker$2010/L@kers2010/L@ker\$2010refs/pull/*/head(13 refs)All 18 feature branches force-updated in the same push.
Verification
Operator action required after this merges
To complete the purge, an admin on the Gitea VM needs to drop the 13
refs/pull/*/headrefs. Recipe is in the newdocs/SECURITY.mdsection. Until that runs, the old commits are still reachable by SHA through the Gitea web UI (/pulls/<n>/filestab), though not through the normal clone or any branch.Deferred (user's call)
docs/SECURITY.mdsection 1–4 is unchanged from PR #3. User flagged this would be done on ops side with fresh credentials provided to a future Devin session.Two small follow-ups to the out-of-band git-history rewrite that purged L@ker$2010 / L@kers2010 / L@ker\$2010 from every branch and tag: .gitleaks.toml: - Regex was L@kers?\$?2010 which catches the expanded form but NOT the shell-escaped form (L@ker\$2010) that slipped past PR #3 in scripts/setup-database.sh. PR #13 fixed the live leak but did not tighten the detector. New regex L@kers?\\?\$?2010 catches both forms so future pastes of either form fail CI. - Description rewritten without the literal password (the previous description was redacted by the history rewrite itself and read 'Legacy hardcoded ... (***REDACTED-LEGACY-PW*** / ***REDACTED-LEGACY-PW***)' which was cryptic). docs/SECURITY.md: - New 'History-purge audit trail' section recording what was done, how it was verified (0 literal password matches in any blob or commit message; 0 legacy-password findings from a post-rewrite gitleaks scan), and what operator cleanup is still required on the Gitea host to drop the 13 refs/pull/*/head refs that still pin the pre-rewrite commits (the update hook declined those refs over HTTPS, so only an admin on the Gitea VM can purge them via 'git update-ref -d' + 'git gc --prune=now' in the bare repo). - New 'Re-introduction guard' subsection pointing at the tightened regex and commit78e1ff5. Verification: gitleaks detect --no-git --source . --config .gitleaks.toml # 0 legacy hits git log --all -p | grep -cE 'L@ker\$2010|L@kers2010' # 0