Nachdem du ein Repo in Zhipu ZCode öffnest, wer packt .env, gelöschte Schlüssel und die komplette Git-Historie noch und lädt sie hoch

Ein Coding-Assistent muss Code lesen, bevor er eine Funktion ergänzt oder einen Fehler behebt. Du öffnest ein Repo und gehst davon aus, du habest die wenigen Dateien in diesem Arbeitsbaum übergeben, die diese Aufgabe braucht. Sitzt .env schon in .gitignore, behandeln das viele als «der Assistent sieht sie nicht, die Cloud erst recht nicht». Am 18. September 2026 hat der Entwickler ferstar die nächste Schicht festgehalten: Nach dem Login baut Zhipus offizieller Desktop-Client ZCode auf diesem Rechner einen Workspace-Snapshot. Der Brocken in dieser Liste ist nicht src/. Es ist das komplette .git-Verzeichnis.

Ein früherer Text hat geklärt, welche Zeichen du maskieren musst, bevor du ein Passwort in ChatGPT oder Gemini einfügst: Das ist eine Kette, die du selbst in den Prompt gelegt hast. Hier wechselt die Frage. Du hast .env nie in den Chat geklebt. Nehmen Objektdatenbank, LFS-Cache und Reflog in einem Workspace-Snapshot trotzdem Schlüssel mit, die du schon gelöscht hast. Muss ein Schlüssel wandern, nimm einen Einmal-Link der Form s.html?id=…#…. Anlegen und Lesen öffnen beide ohne Konto. Die Tools von MyPassGen öffnen ohne Anmeldung. Der Rest dieser Seite zerlegt keinen Client und erklärt nicht, wie du den Upload eines anderen blockierst. Er legt die Zahlen nebeneinander, die schon in ferstars Rekonstruktion vom 18. September 2026 und in der gleichentägigen ITHome-Wiedergabe der offiziellen Notiz stehen, plus das Checkpoints-Verzeichnis, das du auf diesem Rechner öffnen kannst.

Ein Repo öffnen heißt nicht: nur diesen Baum abgeben

Eine Funktion, die du in den Chat klebst, ist der Kontext, den du gewählt hast. Ein Workspace-Snapshot ist ein anderer Weg: Der Client packt das Repo, das du geöffnet hast, und der Umfang kann größer sein als «die Dateien, die dieser Prompt braucht». Nachdem ferstar die Liste nach Größe aufgeteilt hat, machten .git/lfs/, .git/objects/ und .git/logs/ zusammen etwa 86,6 % aus. Quelltext und Docs lagen bei etwa 13,4 %. Selbst wenn dieses Verzeichnis .env schon gelöscht hat, kann ein altes Blob in der Objektdatenbank also mitfahren.

Das ist nicht derselbe Weg wie «hat diese Website das Passwort, das ich gerade erzeuge, als Geschäftsdaten geschickt». Auf der Generatorseite von MyPassGen kannst du im Network prüfen, dass der Klartext nicht als Geschäftsdaten rausgeht. Ein Desktop-Assistent, der einen Snapshot packt, nutzt sein eigenes lokales Verzeichnis und seine eigene ausgehende Verbindung. Eine Datei, die du mit git rm nimmst, ist oft «nicht in diesem Baum», nicht «nie in der Historie vorgekommen». Einen unmaskierten Schlüssel in einen Commit zu schreiben ist dieselbe Klasse wie ein Passwort im Mailtext: Die Gegenseite sieht eine Kopie, die du einmal absichtlich hinterlassen hast. Dieser Weg steht in Wenn du ein temporäres Passwort in den Mailtext schreibst, was Gesendet, Weiterleitung und Handy-Vorschau noch behalten.

Eine weitere Schicht vermischt sich leicht. .gitignore blockiert «diesen Pfad künftig nicht mehr verfolgen». Es blockiert nicht «dieser Pfad war einmal committet». Liest der Assistent nur Dateien im aktuellen Baum, helfen Ignore-Regeln noch. Packt ein Snapshot das ganze .git-Verzeichnis, helfen sie nicht. Ein lokaler Branch, den du nie gepusht hast, Operationen, die noch im Reflog sitzen, und eine interne Repo-URL in .git/config gehören alle zu der Menge «dieser Editortab sieht sie nicht, die Objektdatenbank hat sie noch». Die deutsche GitHub-Hilfe zu vertraulichen Daten im Repository sagt dasselbe in einer anderen Reihenfolge: Erst Secrets widerrufen, dann den Verlauf anfassen. Löschen plus Ignore reicht nicht.

Die Zahlen vom 18. September

ferstar schrieb, der Ausgangspunkt sei ~/.zcode mit mehr als 700 MB gewesen. v2/checkpoints/ lag bei etwa 303 MB. Darin saß eine .enc von etwa 313 MB. Die Statusdatei notierte etwa 345 MB vor dem Packen, 313.070.842 Byte nach der Verschlüsselung, kind baseline und einen failureCount von 564. Dieser Snapshot eines kommerziellen Projekts blieb lokal in pending; die Rekonstruktion sagt, er sei nicht hochgeladen. Ein viel kleineres öffentliches Repo war ein anderer Fall: 538 Dateien, etwa 15 KB nach Kompression und Verschlüsselung, Status vom Server empfangen. Also «ist wirklich etwas rausgegangen» — mindestens dieses eine Mal das kleine Repo.

Dieselbe Dateiliste des kommerziellen Projekts: 42.411 Dateien; .git/lfs/ etwa 196,1 MB (56,8 %), .git/objects/ etwa 102,2 MB (29,6 %), .git/logs/ etwa 0,6 MB (0,2 %). Eine separate Community-Reproduktion schrieb, auf ZCode 3.12.3 sei ein Projektsnapshot etwa 748 MiB groß gewesen, .git etwa 98,91 %. Bei den Auslösern nennt die Rekonstruktion captureBeforePrompt vor einer Frage und repo-wiki-update am Ende einer Aufgabe. In einem aktiven Sitzungslog tauchte die Snapshot-Erfassung bis zu 62 Mal auf.

Die offizielle Notiz ging am 18. September um 17:44 Uhr raus. ITHome hat sie noch am Abend wiedergegeben. Die Punkte: Das Thema saß in der «Code-Repository-Indexierung», genutzt für einen lokalen Index, Rollback über Sitzungs-Checkpoints und Repo Wiki; eine Wiki-Seite in der Cloud zu erzeugen «kann» einen Upload von Repository-Daten auslösen; nach der Wiki-Erzeugung werde dieser Upload sofort vernichtet und nicht behalten; die Funktion war im frühen Start standardmäßig an, ein Teil der Nutzer betroffen, das Problem «bereits behoben»; ZCode werde bald quelloffen, mit einer Prüfung durch Dritte; jede Nutzerin bekomme eine extra wöchentliche Kontingent-Zurücksetzung. Der Anbieter hat nicht bestritten, dass ein Upload stattgefunden hat. Offen bleiben der Upload-Umfang, ob du ihn damals abschalten konntest, und wie «sofort vernichtet» von außen prüfbar ist. Am 20. September hat InfoQ ein Schreiben von Taiyuan Chengming Technology an Beijing Zhipu Huazhang wiedergegeben: Löschung, Datenfluss, Logs und wer haftet. Das ist eine Frage auf Unternehmensseite. Es ist keine Vernichtungsquittung, die du auf diesem Rechner öffnen kannst.

.git ist der Brocken: gelöschte Schlüssel sitzen in den Objekten

Keine .env im aktuellen Arbeitsbaum beweist nur: Dieser Checkout hat diesen Pfad nicht. Git legt Blobs nach Inhalt ab. Hat ein Commit einmal DATABASE_URL= oder AWS_SECRET_ACCESS_KEY= geschrieben und du hast die Datei später geändert, neu committet oder sogar von diesem Branch gelöscht, sitzt das alte Blob oft weiter in .git/objects, bis ein Garbage Collect es wirklich fallen lässt. Ein LFS-Cache kann historische große Dateien behalten. Das Reflog notiert, welche Branches du auf diesem Rechner verschoben hast. Packst du diese drei ins Snapshot, hält die Cloud nicht «diesen Bildschirm im Editor». Sie hält die Historie, die dieses Repo hier angesammelt hat.

Die Rekonstruktion schrieb außerdem: Workspace-Filter schließen einige Secret-Dateien aus, .git ging trotzdem ins Paket. Dieser Satz verdient eine Pause. Heute schiebst du .env aus dem Repo und lässt nur .env.example. Dieser Baum sieht sauber aus. Der Fehlcommit vom letzten Jahr sitzt weiter in der Objektdatenbank. Ein Filter, der nur Pfade im Arbeitsbaum ansieht, nimmt ihn nicht raus. Ein interner GitLab-Hostname in .git/config und ein Feature-Branch, der dieses Notebook nie verlassen hat, leben in Refs und im Reflog. «Ich habe es schon in gitignore» holt das nicht zurück.

Du kannst das mit «ein geleakter Passwort-Hash ist nicht dasselbe, als hätte jemand den Klartext schon gelesen» vergleichen. Ein Hash ist eine Einwegablage, und du rotierst trotzdem. Ein Schlüssel in der Git-Historie ist oft der Klartext selbst. Diesen Rechner gegen eine übliche Liste schwacher Passwörter zu halten beweist nur einen Treffer auf einer öffentlichen Liste. Es beweist nicht, ob ein bestimmter Snapshot deinen alten Commit mitgenommen hat. Dieser Unterschied steht in Lokale Sperrliste und Have I Been Pwned: was jede Prüfung beweist. Rotiere die Menge, die einmal in einem Commit lag, nicht den Blick, der sagt «dieser Baum ist jetzt sauber».

Verschlüsselt heißt nicht: nur du kannst entschlüsseln

Die ausgehende Form, die die Rekonstruktion nachzeichnet, sieht so aus: Der Client fragt bei zcode.z.ai nach Upload-Credentials für den Snapshot und bekommt einen Objektschlüssel, ein Größenlimit und einen RSA-öffentlichen Schlüssel. Dieser Rechner packt den Workspace als tar.gz, verschlüsselt ihn mit AES-256-CTR, hüllt den symmetrischen Schlüssel mit diesem öffentlichen Schlüssel und schickt tar.gz.enc direkt an Aliyun OSS. Der private Schlüssel bleibt die ganze Zeit in der Cloud. Die mehreren hundert Megabyte .enc auf der Platte gehen für dich nicht auf, und sie gehen für den Client nicht auf. Der Algorithmusname sagt AES-256. Das löst «Pfad und Bucket sind keine Klartextdatei». Es gibt dir nicht das Entschlüsselungsrecht.

Das ist dieselbe Grenze wie eine Cloud-Seite, die «verschlüsselt» schreibt. Hält der Anbieter den Schlüssel, kann die Speicherseite die Datei weiter öffnen. Verschlüsselst du zuerst mit einem Passwort, das du hältst, soll die Gegenseite nur Geheimtext sehen. Der Unterschied ist nicht, ob die vier Buchstaben AES vorkommen. Er ist, wer den privaten Schlüssel oder das Passwort hält. Die Datei-Verschlüsselung von MyPassGen macht AES-256-GCM im Stream im Browser, eine Datei bis 5 GB, Ausgabe .lock / .enc, und öffnet ohne Konto. Das Passwort schickst du auf einem anderen Weg. Die Datei geht nicht als Geschäftsdaten hoch. Der Umschlagschlüssel jenes ZCode-Snapshots nutzte einen vom Server ausgegebenen öffentlichen Schlüssel und einen beim Server gehaltenen privaten Schlüssel. Das Ziel ist das Gegenteil: Der Server soll entschlüsseln können. Siehe Bevor die Datei in die Cloud kommt: wer den Klartext sieht und welchen Weg das Passwort nehmen darf.

Die offizielle Notiz sagt, der Upload werde nach der Wiki-Erzeugung sofort vernichtet und nicht behalten. Passiert diese Vernichtung auf dem Server, prüfst du Backups, Objekt-Versionen oder Kopien des privaten Schlüssels von diesem Rechner aus nicht. ferstar schrieb, in 3.14.0 sei der Upload-Pfad aus dem Client verschwunden, upload-credential habe 404 geliefert und nur ein lokaler Checkpoint sei geblieben. Das kann beweisen: «Dieser neue Client fragt nicht mehr nach diesen Credentials.» Es kann nicht beweisen: «Der Snapshot des kleinen Repos, den der Server schon empfangen hat, ist aus jeder Kopie physisch weg.» «Es war verschlüsselt» als «nur ich kann es sehen» zu lesen überspringt die Rotation, die du trotzdem tun musst.

Einen Schalter ausmachen stoppt das Packen nicht

Die Rekonstruktion hat zwei Schalter gegen den Codepfad gelegt. optimizeAgentExperienceEnabled (Erfahrung optimieren) deckt ab, ob Daten zum Trainieren genutzt werden dürfen. Nach dem Ausschalten packt der Snapshot weiter. repoSnapshotIndexingEnabled (Repo-Snapshot-Index) deckt ab, ob der Server nach dem Empfang einen Index baut. Nach dem Ausschalten läuft das lokale Packen weiter. Auf 3.12.3 kam die Capture-und-Upload-Logik hoch, sobald der Login ein JWT ausgeliefert hatte. Die Oberfläche hatte keinen eigenen Schalter «nicht packen und nicht hochladen». Die offizielle Notiz listete kein Kästchen, das du abhaken und danach vor Ort prüfen kannst, dass der ausgehende Verkehr steht. Sie sagte: Die Funktion war am Anfang standardmäßig an, und das Problem sei bereits behoben.

Deshalb sind «ich habe Repo Wiki nie eingeschaltet» und «ich habe das Training ausgemacht» kein Freibrief für 3.12.3. Maßgeblich ist, ob dein Checkpoints-Verzeichnis damals eine neue .enc hatte und ob der Status pending oder empfangen war. Nach dem Wechsel auf die 3.14.0, die die Rekonstruktion nennt, dasselbe Verzeichnis noch einmal ansehen: Wächst ein neues ausstehendes Paket, und liefert die Credential-URL weiter Erfolg. Der Client kann sich heiß aktualisieren. Versionsnummer und dieses Verzeichnis sind zwei Dinge, die du mehr als einmal ansehen kannst. Eine Schlagzeile ist das nicht.

Ein Abzug der offiziellen Datenschutzerklärung, gespeichert am 18. September, zeigte weiter eine letzte Änderung vom 15. Juni 2026. Die Erklärung schrieb, das Produkt sammle Text, Dateien und Code, die in einer Unterhaltung abgeschickt werden — der übliche Rahmen für einen Assistenten, der ein Modell aufruft. Die Rekonstruktion hält fest: Die Seite sagte damals nicht, ein Snapshot des ganzen Repos oder die volle Git-Historie gehe in die Cloud. Widersprechen sich ein Satz in der Erklärung und eine lokale Dateiliste, gilt die Liste und die Statusdatei. Arbeite nicht rückwärts von «ich habe der Datenschutzerklärung zugestimmt» zu «also hat nur der Absatz im Chatfenster den Rechner verlassen».

Nebeneinander: dieser Baum, Git-Historie, der Chat

Derselbe Testschlüssel, der einmal in ein Repo geraten ist, teilt sich in mindestens vier Wege «wer kann ihn noch lesen». Der Unterschied ist nicht die Assistentenmarke. Er ist, wohin eine Kopie gewandert ist und wer das Entschlüsselungsrecht hält.

Die fünfte Zeile nicht mit den ersten vier vermischen. Schreibst du eine volle s.html?id=…#… ins Repo und öffnest dann den Assistenten, können Historie und Snapshot den ganzen Nachweis mitnehmen. Der Dienst, der den Geheimtext nur lagert, sieht den Schlüssel weiter nicht. Nummer und Schlüssel trennen, und eine Volltextsuche findet keinen Link, der aufgeht. Ein vollständiger Link bleibt ein Passwort. Zuerst verschlüsseln, dann synchronisieren gilt für eine Datei. Sobald die Objektdatenbank Klartext gesehen hat, wischt ein späteres .lock das alte Blob nicht weg.

Vor Ort prüfen

Diese Schritte hängen an keinem Markenversprechen. Nutze ein Testpasswort und ein Wegwerf-Repo, das sich nicht in ein echtes Arbeitskonto einloggt und nicht auf ein Firmen-Repo zeigt. In einem leeren Verzeichnis eine Zeile wie orange-lake-7 committen, dann löschen. Nicht mit einem Masterpasswort üben, das du noch benutzt, nicht mit einem Produktions-API-Schlüssel und nicht mit einem lebenden Einmal-Link.

1. Die Version auf der Info-Seite von ZCode oder auf dem Installer lesen. Die Rekonstruktion nennt 3.12.3 als Problemstand und 3.14.0 als Stand, der den Upload-Pfad entfernt hat. Es gilt die Zahl, die du jetzt liest. Eine Gruppenankündigung ersetzt diesen Blick nicht.
2. v2/checkpoints unter der lokalen Datenwurzel öffnen (unter macOS und Linux oft ~/.zcode/v2/checkpoints; unter Windows das Benutzerverzeichnis nach der Installation). Liegt eine .enc da, und daneben eine Status-JSON. Felder, die du öffnen kannst: ob workspacePath ein Projekt ist, das du nie geöffnet zu haben glaubtest, encryptedSizeBytes, failureCount, kind. Ein passender Pfad heißt: Dieser Rechner hat dieses Repo gepackt. Ein hoher failureCount heißt nur, dass dieses Paket nicht rausgegangen ist. Er beweist nicht, dass kein anderes Repo je durchgekommen ist.
3. Ein leeres Test-Repo anlegen, ein Testpasswort committen, dann aus diesem Baum löschen. Mit git log -p oder git log --all --full-history -- Dateiname prüfen, ob der alte Commit noch da ist. Ist er da, rettet «ich habe es schon gelöscht» die Objektdatenbank nicht. Das ist Gits eigenes Verhalten, mit oder ohne Assistent. Packt ein Snapshot .git, ist das die Schicht, die er liest.
4. Hat 3.12.3 dieses Test-Repo je geöffnet: Zurück zu den Checkpoints und sehen, ob ein neues Paket zu diesem Pfad passt. Nach einem Upgrade eine Weile beobachten: Wächst eine neue ausstehende .enc. Lokale Dateien sind Belege, die du mehr als einmal ansehen kannst. Du musst den Client eines anderen nicht zerlegen und sollst es nicht.
5. Jedes Passwort, jedes Token und jede interne Adresse, die je in ein echtes Repo geraten ist, als «hat diesen Rechner schon verlassen» behandeln: Am Ursprungsdienst rotieren und ein neues Zufallspasswort erzeugen. Der Passwortgenerator von MyPassGen nutzt den Zufallsmodus 6–128 Zeichen, Standard 16, unter 8 einen Hinweis auf schwächer. Er öffnet ohne Konto. Das Ergebnis geht nicht als Geschäftsdaten hoch. Für eine wiederverwendete Kette Passwortstärke nutzen und diesen Rechner gegen eine übliche Liste schwacher Passwörter halten. Das kann einen Treffer auf einer öffentlichen Liste beweisen. Es kann den Umfang eines bestimmten Snapshots nicht beweisen.
6. Einen MyPassGen-Einmal-Link mit demselben Testsatz anlegen, Ablauf 24 Stunden, Abrufe bei 1 lassen. In Chat oder Ticket nur den Teil vor der Raute kleben, s.html?id=…. Den Schlüssel am Telefon oder persönlich sagen. Öffnet ohne Konto. Mit nur der Nummer soll die Empfängerin einen unvollständigen Link sehen; beide Hälften braucht die Entschlüsselung. Nach dem Lesen die Zwischenablage überschreiben. Keine Adresse mit # ins Repo schreiben und die Ergebnisseite nicht in irgendeinen Assistenten-Chat kleben.

Beim Firmen-Repo eine halbe Stufe extra: Fragen, welche Wurzeln der Assistent standardmäßig öffnet, ob ein Secrets-Verzeichnis außerhalb des Workspace bleiben kann und ob historische Snapshots eine Löschquittung auf Unternehmensseite haben. MyPassGen entscheidet nicht, ob eine bestimmte Cloud eine weitere Kopie behalten hat. Es gelten die Fenster, die du gerade geöffnet hast, und das Git-Log.

Wenn der Schlüssel wandern muss, teile den Kanal

Für eine Eins-zu-eins-Übergabe, die die Gegenseite jetzt öffnen kann, das Passwort nicht in eine Datei schreiben, die in Git, in einen Assistenten-Workspace und in der Objektdatenbank landet. Auf diesem Gerät erzeugen, dann in einen Einmal-Link packen. Beim Anlegen verschlüsselt der Browser mit AES-256-GCM. Eine einzelne Notiz endet bei 32 KB. Abrufe starten bei 1 und enden bei höchstens 10. Ablauf kann 1 Stunde, 24 Stunden, 7 Tage oder nur Zähler ohne TTL sein. Der Server lagert nur Geheimtext. Der Schlüssel sitzt hinter # in der URL, Access-Log und Referer sehen dieses Stück nicht. Ein Repo und ein Assistenten-Chatfenster können es trotzdem sehen. Den vollen Link nicht in einen Commit schreiben.

Braucht ein Repo oder ein Ticket trotzdem einen Einstieg, den Kanal teilen. Die Datei trägt nur die Verantwortliche, die Nummer und den Satz «Schlüssel per Telefon». Ein Anruf, eine Übergabe vor Ort oder ein anderes Messenger-Konto trägt nur das Stück hinter #. Keine Hälfte entschlüsselt allein. Das ist ein Nutzungsmuster, kein Produktstandard. Die Anlege-Seite gibt weiter einen vollen Link aus, praktisch für eine Eins-zu-eins-Sendung. Auf einem Kanal, der Vorschaukarten zeichnet, zuerst einen Testlink laufen lassen und sehen, ob die Vorschau einen Abruf zählt, wie in Wenn du einen Einmal-Link in Slack oder WeChat einfügst, verbraucht die Link-Vorschau ihn zuerst. Fehler- und Config-Auszüge zuerst in Links säubern maskieren, dann entscheiden, ob sie noch in einen Assistenten müssen.

Ein Schlüsselpaket oder ein Export über 32 KB gehört nicht auf einen Einmal-Textlink. Die Datei-Verschlüsselung nutzen: AES-256-GCM im Stream im Browser, eine Datei bis 5 GB, Ausgabe .lock / .enc, Passwort getrennt schicken. Zuerst auf diesem Gerät verschlüsseln, dann synchronisieren; die Gegenseite soll nur Geheimtext sehen. Eine unmaskierte .env nach Git zu schieben ist dieselbe Klasse wie ein unverschlüsseltes Zertifikatspaket in die Cloud: Die Kopie, die beweist «das ist der Schlüssel», hat den Arbeitsbaum verlassen, den du schon für sauber hieltst. Wie du vor Ort prüfst, dass Browser-Verschlüsselung keinen Klartext als Geschäftsdaten geschickt hat, steht in Wie du prüfst, dass Browser-Verschlüsselung keinen Klartext hochlädt.

Nachdem du «liegt in Checkpoints eine .enc zu diesem Pfad», «druckt git log das Testpasswort noch» und «räumt nur ein Client-Upgrade einen alten Snapshot» geprüft hast, kannst du die Frage dieses Texts schon beantworten: .env aus diesem Baum zu löschen leert die Objektdatenbank nicht, und es leert einen schon gepackten Snapshot nicht. Die offizielle Korrektur trifft den Client-Pfad, den sie ändern können. Ein Paket, das der Server schon empfangen hat, und Klartext in deinen alten Commits werden nicht leer, weil du einmal aktualisiert hast. Das lokale Verzeichnis und das Git-Log sind ein Ort zum Prüfen. Sie sind ein schlechter Ort für die Annahme «ich habe den Schlüssel nie in den Chat geklebt, also ist das erledigt».

Häufige Fragen

Ich bin schon aktualisiert. Sind die alten Snapshots damit auch weg?

Das sind verschiedene Aufgaben. Ein neuer Build blockiert die nächste Credential-Anfrage und den direkten Upload. Eine alte .enc auf diesem Rechner, die Statusdatei und die Cloud-Kopie, die der Anbieter «nach der Erzeugung vernichtet» nennt, liegen nicht in diesem Update-Klick. Es gilt, ob Checkpoints noch hier liegen und ob ein lebender Schlüssel rotiert ist.

Dieser Baum hat .env schon in gitignore. Muss ich trotzdem rotieren?

Die Historie lesen, nicht diesen Baum. Eine Ignore-Regel blockiert nur künftiges Verfolgen. Lag in einem alten Commit Klartext, behandle ihn als schon kopiert. Einmal git log an einem Test-Repo ist direkter als einem Filter zu glauben.

Der Snapshot ist verschlüsselt. Kann ich das als nie geleakt werten?

Nein. Die Rekonstruktion sagt, der private Schlüssel bleibt in der Cloud. Den lokalen Geheimtext öffnest du selbst nicht. Verschlüsselung verhindert «ein Klartext-Tar liegt im Bucket». Sie heißt nicht «nur die Repo-Besitzerin kann lesen». Lässt sich die Vernichtung von außen nicht beweisen, behandle Schlüssel, die je in Git lagen, als Material, das du rotieren musst.

Brauchen Anlegen und Lesen ein Konto? Kann der Support den falschen Kanal retten?

Keine Anmeldung. Anlegen und Lesen sind für Besuchende offen. Nachdem der Geheimtext nach Zähler oder Ablauf verbrannt ist, gibt es kein Klartext-Backup auf dem Server und kein Support-Postfach, das ihn zurückholt. Ein neues Passwort und einen neuen Link erzeugen. Dieselbe URL nicht immer wieder aktualisieren, ob sie zurückkommt, und die Ergebnisseite nicht ins Repo schreiben, um sie nachzuschicken.