Naar de hoofdinhoud

Repository's migreren met secrets in de geschiedenis

fremforge voert bij elke push een gitleaks-pre-receive-hook uit, ook bij de eerste mirror-push die de geschiedenis van een klant naar een fremforge-organisatie brengt. Staan er in een historische commit van de bronrepository secrets (een oud .env-bestand, een gelekte API-sleutel, een private SSL-sleutel enzovoort), dan mislukt de importpush en loopt de migratie vast.

Deze pagina beschrijft de twee ondersteunde opties. Optie A is voor de meeste teams de aanbevolen route; optie B is een laatste redmiddel.

Optie A: roteer het secret en herschrijf de geschiedenis (aanbevolen)

Het meest geschikt als:

  • Het gelekte secret echt is (API-sleutel, private SSH-sleutel, certificaat, wachtwoord). Het moet hoe dan ook ongeldig worden gemaakt, waar de repository ook staat: het in de git-geschiedenis van welke host dan ook laten staan, is een blijvende blootstelling.
  • Het team ongeveer een uur kan besteden aan het herschrijven van de geschiedenis en een force-push naar de bron.

Procedure:

  1. Roteer eerst het gelekte secret. Voordat je git aanraakt: wijzig de API-sleutel, trek de SSH-sleutel in, roteer het certificaat. De gelekte waarde moet ongeldig zijn voordat de geschiedenis wordt herschreven; dan is de waarde onschadelijk, zelfs als het herschrijven onvolledig is.
  2. Zoek de commit(s). De gitleaks-uitvoer van de importpoging in fremforge noemt de regel en de commit-SHA. Zorg dat je begrijpt om welk secret en welke commits het gaat.
  3. Herschrijf de geschiedenis met git filter-repo. (upstreamdocumentatie)
    # Install: brew install git-filter-repo  (or pip install git-filter-repo)
# Verify upstream is clean:
git clone --mirror <source-url> repo.git
cd repo.git
# Replace the secret value across history (string-replace shape):
echo 'literal:AKIAEXAMPLE12345===>REDACTED' > replace.txt
git filter-repo --replace-text replace.txt
# OR: drop the file containing the secret across history:
git filter-repo --invert-paths --path path/to/leaky/file
  4. Force-push de herschreven geschiedenis eerst naar de bronrepository.
    • Het herschrijven van de geschiedenis aan de bronkant maakt de oplossing blijvend. Push je de herschreven geschiedenis alleen naar fremforge, dan heeft een aanvaller die de bron vóór het herschrijven heeft gekloond de gelekte waarde nog steeds.
    • GitHub: git push --force-with-lease --mirror
    • GitLab en ADO: hetzelfde. Beide weigeren standaard een force-push naar beschermde branches; versoepel dat tijdelijk, push en zet de bescherming terug.
  5. Voer de migratie uit volgens de standaardprocedure, zie github / gitlab / azure-devops.
  6. Controleer na de import dat het gitleaks-log van fremforge voor de migratiepush nul blokkades toont.

Kanttekeningen:

  • Forks en clones bevatten nog de oorspronkelijke geschiedenis. Je kunt niet elke clone terughalen; daarom is stap 1 (eerst het secret roteren) de stap waar alles om draait.
  • Het herschrijven van de geschiedenis breekt elke open PR/MR/branch op de bron. Stem het af met het team voordat je op enter drukt; sommige hosts ronden PR’s netjes af bij een rebase, andere tonen ze als “merged in N+1 commits”.
  • De integriteit van tags en handtekeningen gaat verloren: een ondertekende tag die naar een herschreven commit wijst, is niet langer geldig. Maak de tags na het herschrijven opnieuw aan.

Optie B: begin met een lege repository en push alleen de laatste commit (laatste redmiddel)

Het meest geschikt als:

  • De geschiedenis van de bron te verward is om netjes te herschrijven.
  • Het team bereid is af te zien van alle blame- en loggeschiedenis; alleen de huidige toestand telt.
  • Gebruikelijk bij gearchiveerde projecten die “ter bewaring” worden gespiegeld, zonder actieve ontwikkeling.

Procedure:

  1. Kloon de laatste tree van de bronrepository (elke branch volstaat) naar een werkmap.
  2. rm -rf .git && git init && git add . && git commit -m "Initial import: <source-url>@<commit-sha>".
  3. Push de nieuwe repository met één commit volgens de standaardprocedure naar fremforge.
  4. Voeg een NOTES.md of een link in de CHANGELOG toe die terugverwijst naar de bron, voor teamleden die de volledige geschiedenis nodig hebben.

Wat je hiermee verliest:

  • Alle geschiedenis van git blame / git log.
  • Alle historische diffs van PR’s en MR’s (die blijven op de bronhost staan totdat je die verwijdert).
  • Alle historische commithandtekeningen.

Kiezen tussen de twee

VraagOptie AOptie B
Is het secret nog geldig?eerst roterenn.v.t.
Moet de geschiedenis behouden blijven?herschrevenweggegooid
Eenmalige push?jaja
Gaat nieuw werk door in dezelfde repository?jaja
Zijn er nog forks/clones met het lek in omloop?alleen een restrisico als het niet is geroteerdn.v.t. (geschiedenis niet in fremforge)
Is een handeling van een operator nodig?neenee

Kies standaard voor A, tenzij er een sterke reden is om dat niet te doen.

Gerelateerd

Naast GitHubControle vóór de migratie