>

instant-thinking.de

just enough to get you started and leave you confused

Dateien und Passworte aus git entfernen

| Kommentare

Der Post über das Nutzen der macOS Keychain für die Passworte in der imapfilter config hatte einen recht unerquicklichen Hintergrund: Ich habe froh und glücklich an Konfiguration und Regeln für imapfilter geschraubt, ohne daran zu denken, dass Passworte in Klartextdateien eine Doofe Idee™ sind. Die config.lua befindet sich außerdem in meinem dotfile repo und ich habe so einige Commits auf diese Datei gesammelt. Wie kann man das nun wieder alles loswerden1, ohne alles zu verlieren?

Das kommt so häufig vor2, dass git dafür3 ein passendes Kommando namens git-filter-branch hat. Die Doku beginnt direkt mit dieser erheiternden Warnung:

git filter-branch has a plethora of pitfalls that can produce non-obvious manglings of the intended history rewrite (and can leave you with little time to investigate such problems since it has such abysmal performance). These safety and performance issues cannot be backward compatibly fixed and as such, its use is not recommended. Please use an alternative history filtering tool such as git filter-repo. If you still need to use git filter-branch, please carefully read SAFETY (and PERFORMANCE) to learn about the land mines of filter-branch, and then vigilantly avoid as many of the hazards listed there as reasonably possible.

Plethora of pitfalls, abysmal performance, land mines… Haha, das will man dann eigentlich lieber nicht benutzen. Für die allerallermeisten Anwendungsfälle ist offenbar BFG4 am allerallereinfachsten zu benutzen. Mindestens trifft das auf das Entfernen von Dateien zu, wie ich hier lernen konnte.

Installation

Dank homebrew ist man unter einem einigermaßen aktuellem macOS nach einem brew install bfg schon einsatzbereit und muss sich mit Java und anderem Ungemach überhaupt nicht befassen5.

Backup

Es empfiehlt sich6 ein Backup anzulegen, bevor man zu Werke geht. git clone --mirror git@some.origin/reponame reponame-backup.git sollte völlig ausreichen.

Repo aufräumen

Das ist ein wichtiger Teil: BFG erwartet, dass man das Repo in einem aktuell sauberen Zustand vorliegen hat, also alle geheimen Geheimnisse in HEAD beseitigt sind. In meinem Fall habe ich also die config.lua aus meinem .imapfilter-Verzeichnis in meinem .dotfiles Repo entfernt und die viel bessere config.lua.example erstellt. Dann ein Commit und wir können im nächsten Schritt an das Entfernen der Datei aus der History gehen.

Datei aus History entfernen

In meinem Falle war das Problem mit einem bfg --delete-files config.lua so gut wie aus der Welt geschafft. BFG geht zu Werke, berichtet,7 was alles getan wurde und sagt Bescheid, dass nun noch die physischen Dateien gelöscht werden müssen. Das klappt dann per git reflog expire --expire=now --all && git gc --prune=now --aggressive.

Neue History verteilen

Weil ich in meinem echten Repo gearbeitet habe, habe ich die neue History per git push --force in meine Remotes verteilt.

Obacht: Solange es noch Repos gibt, die die alte Wahrheit beinhalten ist die Datei bzw. das geheime Geheimnis noch in der Welt. Insbesondere bei mehreren Usern ist daher Kommunikation vonnöten, um die anderen Repos mit dem neuen Stand zu versorgen.

Am besten ist es, wie immer, vorher zu überlegen, ob es nicht eine gute Idee wäre, Usernamen und Passworte aus verteilten Repositories herauszuhalten. In den folgenden via-Links ist auch noch einmal notiert, wie man einzelne Strings entfernt, das hatte ich hier bislang noch nicht ausprobiert, es liest sich aber auch sehr geradeaus.

Passworte erneuern, Schlüssel widerrufen

Sollte schon irgendeines der geheimen Geheimnisse öffentlich geworden sein, kann man das Passwort oder den Schlüssel als verloren betrachten und sollte jetzt sofort aktiv werden und ein neues Passwort vergeben bzw. einen neuen Schlüssel erstellen und den alten widerrufen.

Das Problem zukünfigt schneller bemerken

Es ist eine gute Idee, auch eher kleine, persönliche aber public Repos durch so etwas wie GitGuardian monitoren zu lassen, ein kostenloser Account reicht dafür total aus. Dann bekommt man Bescheid, sobald irgendetwas, das wie ein potentielles Risiko aussieht, im Repo auftaucht.

(via: Vinay Sharma, Touré Holder und Fabian Lee)

  1. Und auch mal wieder zu GitHub pushen…

  2. Menschen, so sind wir…

  3. Und für sehr viele andere Dinge…

  4. Nein, nicht diese BFG

  5. YMMV

  6. Wie eigentlich sehr häufig in der IT…

  7. Im Home-Verzeichnis werden auch entsprechende Logs geschrieben…

Comments