Migrere repositoryer med secrets i historikken

fremforge kjører en gitleaks-pre-receive-hook på hver push, også på den første speil-pushen som henter en kundes historikk inn i en fremforge-organisasjon. Hvis kilderepositoryet har secrets i en eldre commit (en gammel .env, en lekket API-nøkkel, en privat SSL-nøkkel og så videre), feiler import-pushen, og migreringen stopper opp.

Denne siden beskriver de to alternativene vi støtter. Alternativ A er den anbefalte veien for de fleste team; alternativ B er en siste utvei.

Alternativ A: roter secreten og skriv om historikken (anbefalt)

Passer best når:

• Den lekkede secreten er ekte (API-nøkkel, privat SSH-nøkkel, sertifikat, passord). Den må gjøres ugyldig uansett hvor repositoryet ligger; så lenge den ligger i Git-historikken hos en hvilken som helst vert, er den eksponert.
• Teamet kan bruke omtrent en time på å skrive om historikken og force-pushe til kilden.

Fremgangsmåte:

1. Roter den lekkede secreten først. Før du rører Git: bytt API-nøkkelen, tilbakekall SSH-nøkkelen, roter sertifikatet. Den lekkede verdien skal være ugyldig før historikken skrives om; da er verdien ufarlig selv om omskrivingen skulle bli ufullstendig.
2. Finn commiten eller commitene. gitleaks-utdataene fra importforsøket i fremforge oppgir regelen og commit-SHA-en. Forsikre deg om at du forstår hvilken secret og hvilke commits det gjelder.
3. Skriv om historikken med git filter-repo. (upstream-dokumentasjon)

   # 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 den omskrevne historikken til kilderepositoryet først.
   • Det er omskrivingen på kildesiden som gjør rettelsen varig. Hvis du bare pusher den omskrevne historikken til fremforge, har en angriper som klonet kilden før omskrivingen, fortsatt den lekkede verdien.
   • GitHub: git push --force-with-lease --mirror
   • GitLab og ADO: det samme. Begge avviser som standard force-push til beskyttede brancher; løs opp beskyttelsen midlertidig, push, og beskytt på nytt.
5. Kjør migreringen etter standardprosedyren, se GitHub / GitLab / Azure DevOps.
6. Kontroller etter importen at gitleaks-loggen i fremforge viser null blokkeringer for migrerings-pushen.

Forbehold:

• Forker og kloner har fortsatt den opprinnelige historikken. Det finnes ingen måte å hente inn hver eneste klone på, og det er derfor trinn 1 (roter secreten først) er det trinnet alt hviler på.
• Når historikken skrives om, brytes alle åpne PR-er, MR-er og brancher i kilden. Avtal med teamet før du trykker Enter; noen verter avslutter PR-er ryddig ved rebase, andre viser dem som «merged in N+1 commits».
• Integriteten til tagger og signaturer brytes: en signert tag som peker på en omskrevet commit, er ikke lenger gyldig. Tag på nytt etter omskrivingen.

Alternativ B: start fra et tomt repository og push bare siste commit (siste utvei)

Passer best når:

• Kildehistorikken er for floket til å skrives om rent.
• Teamet er villig til å gi slipp på all blame- og logghistorikk; bare dagens tilstand teller.
• Vanlig for arkiverte prosjekter som speiles «for oppbevaring», ikke for aktiv utvikling.

Fremgangsmåte:

1. Klon det siste treet i kilderepositoryet (hvilken som helst branch) til en arbeidskatalog.
2. rm -rf .git && git init && git add . && git commit -m "Initial import: <source-url>@<commit-sha>".
3. Push det nye repositoryet med én commit til fremforge etter standardprosedyren.
4. Legg til en NOTES.md eller en CHANGELOG-lenke som peker tilbake til kilden, for teammedlemmer som trenger hele historikken.

Dette mister du:

• All git blame- og git log-historikk.
• Alle historiske PR- og MR-differ (de blir liggende hos kildeverten til du sletter dem der).
• Alle historiske commit-signaturer.

Velge mellom de to

Velg A med mindre det finnes en sterk grunn mot det.

Relatert

• Migrering fra GitHub · Migrering fra GitLab · Migrering fra Azure DevOps
• pre-migration-check.sh: blar gjennom kilderepositoryene side for side, kryssjekker kompatibiliteten til Marketplace-actions og viser konfigurasjonen av webhooker, branchbeskyttelse og pipelines. Skanner IKKE historikken etter secrets (det er jobben til gitleaks, som du kjører lokalt slik siden over beskriver)
• Sikkerhet og forsyningskjede: gitleaks-hooken denne siden handler om