Hoppa till huvudinnehållet

Migrera repon med secrets i historiken

fremforge kör en pre-receive-hook med gitleaks vid varje push, även den första spegel-push som för in en kunds historik i en fremforge-organisation. Om källrepot har secrets i någon äldre commit (en gammal .env, en läckt API-nyckel, en privat SSL-nyckel osv.) misslyckas import-pushen och migreringen stannar.

Den här sidan beskriver de två alternativ som stöds. Alternativ A är den rekommenderade vägen för de flesta team; alternativ B är en sista utväg.

Alternativ A: byt ut secreten + skriv om historiken (rekommenderas)

Passar bäst när:

  • Den läckta secreten är en riktig (API-nyckel, privat SSH-nyckel, certifikat, lösenord). Den måste ogiltigförklaras oavsett var repot ligger; att lämna den i någon värds Git-historik är en fortsatt exponering.
  • Teamet kan lägga ungefär 1 timme på att skriva om historiken + göra force-push till källan.

Gör så här:

  1. Byt ut den läckta secreten först. Innan du rör Git: ändra API-nyckeln, återkalla SSH-nyckeln, byt ut certifikatet. Det läckta värdet ska vara ogiltigt innan historiken skrivs om; då är värdet ofarligt även om omskrivningen blir ofullständig.
  2. Identifiera commiten eller commitsen. gitleaks-utdatan från fremforges importförsök anger regeln + commitens SHA. Kontrollera att du förstår vilken secret och vilka commits det gäller.
  3. Skriv om historiken med git filter-repo. (uppströmsdokumentation)
    # 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. Gör först force-push av den omskrivna historiken till källrepot.
    • Det är omskrivningen på källsidan som gör åtgärden varaktig. Om du bara pushar den omskrivna historiken till fremforge har en angripare som klonade källan före omskrivningen fortfarande det läckta värdet.
    • GitHub: git push --force-with-lease --mirror
    • GitLab + ADO: samma sak. Båda avvisar force-push till skyddade brancher som standard; lätta tillfälligt på skyddet, pusha och skydda igen.
  5. Kör migreringen enligt standardproceduren, se github / gitlab / azure-devops.
  6. Kontrollera efter importen att fremforges gitleaks-logg visar noll blockeringar för migrerings-pushen.

Förbehåll:

  • Forkar och kloner har fortfarande den ursprungliga historiken. Det går inte att få tillbaka varje klon, och det är därför steg 1 (byt ut secreten först) är det steg som allt vilar på.
  • En omskrivning av historiken förstör varje öppen PR/MR/branch i källan. Stäm av med teamet innan du trycker på enter; vissa värdar avslutar PR:er snyggt vid rebase, andra visar dem som “merged in N+1 commits”.
  • Integriteten för taggar och signaturer bryts: en signerad tagg som pekar på en omskriven commit är inte längre giltig. Tagga om efter omskrivningen.

Alternativ B: börja från ett tomt repo och pusha bara den senaste commiten (sista utväg)

Passar bäst när:

  • Källans historik är för trasslig för att skriva om på ett rent sätt.
  • Teamet kan avstå från all blame-/logghistorik; bara det nuvarande läget spelar roll.
  • Vanligt för arkiverade projekt som speglas “för säkerhets skull” men inte utvecklas aktivt.

Gör så här:

  1. Klona källrepots senaste träd (valfri branch) till en arbetskatalog.
  2. rm -rf .git && git init && git add . && git commit -m "Initial import: <source-url>@<commit-sha>".
  3. Pusha det nya repot med en enda commit till fremforge enligt standardproceduren.
  4. Lägg till en NOTES.md eller en länk i CHANGELOG som pekar tillbaka till källan för teammedlemmar som behöver hela historiken.

Det här förlorar du:

  • All historik i git blame / git log.
  • Alla diffar från äldre PR:er / MR:er (de finns kvar hos källvärden tills du tar bort den).
  • Alla äldre commit-signaturer.

Välja mellan de två

FrågaAlternativ AAlternativ B
Är secreten fortfarande giltig?byt ut förstej tillämpligt
Måste historiken bevaras?omskrivenkasserad
Engångs-push?jaja
Fortsätter nytt arbete i samma repo?jaja
Finns forkar/kloner med läckan kvar ute?kvarstående risk bara om secreten inte bytts utej tillämpligt (historiken finns inte i fremforge)
Krävs en åtgärd av en operatör?nejnej

Välj A om det inte finns ett starkt skäl emot det.

Relaterat

Vid sidan av GitHubKontroll före migrering