Fjern en lekket nøkkel fra Git – sletting av filen rydder ikke historikken

Tilbakekall eller roter den lekkede nøkkelen før du skriver om historikken, slik GitHubs veiledning anbefaler. En ny commit som sletter filen, endrer bare den nyeste versjonen: Eldre commits kan fortsatt inneholde nøkkelen, slik NIHs forklaring av Git-historikk beskriver.

For å fjerne de historiske kopiene må du skrive om berørte commits, oppdatere det sentrale repositoriet og rydde andre kloner. Rekkefølgen er avgjørende. En nøkkel som allerede er eksponert, blir ikke uskadeliggjort av en omskriving alene, og en gammel gren eller klon kan senere føre den opprinnelige historikken tilbake.

Stans endringer før du skriver om historikken

Be alle som kan skyve til repositoriet, om å stoppe mens oppryddingen pågår. Avklar hvem som har åpne grener, tagger, pull requests og arbeid som ennå ikke er delt. Hvis noen skyver nye commits etter at oppryddingen startet, kan en senere tvangsskyving overskrive arbeidet deres, eller du må begynne filtreringen på nytt.

Ta vare på en tilgangsbegrenset sikkerhetskopi av utgangspunktet og noter adressen til det sentrale repositoriet. Sikkerhetskopien inneholder fortsatt nøkkelen og må behandles som sensitiv. Arbeid i en fersk klon, for eksempel opprettet med git clone REPOADRESSE opprydding. Da kan du forkaste klonen og starte på nytt hvis filteret endrer mer enn planlagt. Flagget --sensitive-data-removal henter dessuten referanser som kan peke på lekkasjen; lokale endringer som ikke er delt, hører derfor ikke hjemme i oppryddingsklonen.

Avklar følgene før kommandoene kjøres. Omskrevne commits får nye ID-er, og referanser til de gamle kan slutte å virke. Signaturer kan falle bort, mens åpne pull requests kan få endrede differanser og ugyldige kommentarer. På GitHub kan også differansevisningen for berørte lukkede pull requests gå tapt når interne referanser fjernes. Teamet bør kjenne dette omfanget før den sentrale historikken erstattes.

Velg mellom filfjerning og teksterstatning

Valget avhenger av hva som må bevares. Dokumentasjonen for git-filter-repo beskriver --invert-paths for å fjerne en filsti fra historikken og --replace-text for å erstatte en verdi mens resten av filinnholdet beholdes. Bruk --sensitive-data-removal sammen med filteret for å få informasjon som trengs når andre kopier skal ryddes.

• Hvis ingen historisk versjon av filen skal beholdes, kjør git filter-repo --sensitive-data-removal --invert-paths --path config/.env. Stien er et eksempel og må erstattes med den faktiske stien fra roten av repositoriet. Har filen skiftet navn eller plassering, legg til hver tidligere sti med et eget --path-argument. Filteret følger ikke navneendringer automatisk.
• Hvis filen skal beholdes, legg den lekkede verdien i en tilgangsbegrenset fil utenfor klonen og kjør git filter-repo --sensitive-data-removal --replace-text ../hemmeligheter.txt. Filnavnet er et eksempel. En vanlig linje i uttrykksfilen behandles som bokstavelig tekst; standarderstatningen er ***REMOVED***. Legg ikke selve nøkkelen direkte i kommandolinjen.

Teksterstatning krever at du kjenner verdien og eventuelle andre varianter som ble lagret. Den gjelder filinnhold i ikke-binære filer; en nøkkel i commit- eller taggmeldinger trenger et eget filter, som --replace-message. Er den lagret i en binærfil eller i Git LFS, må den kopien undersøkes og håndteres særskilt. Hvis en fjernet konfigurasjonsfil fortsatt trengs, kan du legge tilbake en ren versjon i en ny commit etter omskrivingen, uten den gamle legitimasjonen.

Kontroller resultatet før noe skyves

Undersøk alle relevante grener og tagger i oppryddingsklonen, ikke bare arbeidskopien. Etter filfjerning kan git log --all --name-status -- config/.env vise om den aktuelle stien fremdeles forekommer i tilgjengelig historikk; gjenta for tidligere stier. Etter teksterstatning må du søke i historiske filversjoner etter den gamle verdien med en metode som ikke lagrer nøkkelen i terminalhistorikk eller logger. Kontroller også om legitimasjonen finnes under andre filnavn eller i en annen form.

Se deretter om nødvendige filer og referanser fortsatt finnes. Filen .git/filter-repo/changed-refs kan hjelpe deg å identifisere pull request-referanser som er berørt. Er omfanget feil, forkast klonen og gjenta filtreringen fra en fersk kopi. Det er det siste enkle stoppunktet: Når den omskrevne historikken er delt, må andre kopier samordnes med den.

Skyv den nye historikken til sentralt repositorium

En vanlig push av den aktive grenen oppdaterer ikke nødvendigvis andre grener og tagger. Kontroller at oppryddingsklonen inneholder referansene som skal bevares, og at ingen har skyvet nye endringer under pausen. git-filter-repo kan fjerne remote-navnet origin; legg det i så fall tilbake med git remote add origin REPOADRESSE etter at adressen er kontrollert.

Før neste kommando må du vite at speilskyving kan overskrive eller slette referanser på serveren som ikke finnes lokalt. Når kontrollen er fullført og pausen er bekreftet, kjør git push --force --mirror origin. Beskyttede grener og vertens interne pull request-referanser kan avvise oppdateringer. På GitHub kan gamle commits dessuten fortsatt være tilgjengelige via cacher, pull requests eller forks etter skyvingen. Der slike kopier må fjernes, må de gjenværende referansene og lagrede objektene håndteres gjennom vertens prosess og eierne av eventuelle forks.

Rydd gamle kloner før arbeidet fortsetter

Gi kollegene beskjed om at de ikke skal merge eller skyve grener som bygger på den gamle historikken. Den enkleste oppryddingen er å erstatte gamle kloner med ferske kloner fra det oppdaterte repositoriet. En utvikler som kjører git pull og deretter git push fra en urenset klon, kan føre de gamle commitene tilbake til sentralt repositorium.

Arbeid som ennå ikke er delt, må tas vare på og legges oppå den nye historikken med rebase, uten å merge den gamle grenen inn. Hvis en klon må beholdes, må eieren også rydde gamle tagger og andre referanser, la gamle reflogger utløpe og fjerne objekter som ikke lenger er i bruk. Disse grepene kan slette lokal historikk og stash-innhold, så arbeidet må sikres først. Klonen må kontrolleres før den får skyve igjen. La ikke hver utvikler kjøre samme filterkommando separat: Selv like kommandoer kan gi ulike nye commit-ID-er og skape flere uforenlige versjoner av historikken.

Hold skrivepausen til det sentrale repositoriet, relevante forks og kloner som skal brukes videre, er avklart. Først da kan nye commits bygges på den rensede historikken uten at en gammel kopi blir en vei tilbake for lekkasjen.

Les også:

• Slik kjøper du SpaceX-aksjen fra Norge – ASK kan ikke brukes
• Citrix-hull utnyttes nå – en oppdatering rydder ikke bort et innbrudd
• Slack eller Discord: 90 dagers historikk kan avgjøre gratisvalget