Fragen? Antworten! Siehe auch: Alternativlos
Im Prinzip ist das mit der Versionierung richtig, nur, äh, git hat diese Möglichkeit, die komplette History zu überschreiben. Auch beim Pushen auf den Server.Tja. git ist leider auch ein Opfer seiner eigenen Überkomplexität geworden. Dabei fing das mal schön einfach und überschaubar an vor vielen Jahren.Also, wenn du möchtest, kann ich dir gerne einen PoC für einen git- Verschlüsselungstrojaner schreiben, der wirklich die ganze History mit verschlüsselt, und die so verschlüsselten Daten auf die zugehörigen Remote- Repositories pusht. Das ist überhaupt kein Thema. Aber man braucht dazu IMHO keinen PoC:
https://stackoverflow.com/questions/10054611/how-to-push-new-rewritten-history-to-remote-repository
Es reicht einfach ein git push --force, und fertig. Kann der Entwickler absichern, in dem er an der Stelle eine Passwort-Eingabe erzwingt, macht aber niemand (Komfort!!!).
Die eigentliche Verschlüsselung würde ich wohl auf git fast-export und git fast-import basieren. Das ist ausgesprochen trivial, einfach die data <bytes> Statements rausfischen, und durch entsprechend verschlüsselte Daten ersetzen. Ich würde für einen PoC maximal ein paar Stunden ansetzen, inklusive Test-Zerstörung und Rekonstruktion eines auf github gehosteten größeren Repositories. Hauptschwierigkeit: Im Dschungel der git-Befehle die richtigen finden, damit nicht versehentlich irgendwas lesbares übrigbleibt.
Update: WOW jetzt kommen hier lauter Leserbriefe rein, dass man das ja wegkonfigurieren kann, und das würde eh alle größeren Projekte machen, bestimmt jedenfalls nachdem sie einmal auf die Fresse geflogen sind damit. Heilige Scheiße, Leute, diese Denke gibt es noch? Ich dachte das hätten wir zivilisatorisch überwunden!
Vergleiche: Die Firma war selber Schuld, die haben ihre Mail-Attachments geöffnet!!1!
Vergleiche: Die hätte halt einen längeren Rock anziehen müssen.
Alle, die mir diesen Leserbrief geschrieben haben: Ihr solltet euch was schämen!