# Post-mortem — Secret TURN affiché en clair par erreur

**Date** : 2026-10-13. **Gravité** : faible (secret révoqué avant toute mise
en service réelle du relais TURN ; aucun élève ni prof concerné).

## Ce qui s'est passé

En vérifiant que Prosody avait bien repris la configuration TURN après le
déploiement, j'ai lancé une commande qui affichait la configuration générée
en clair (`docker exec visio-prosody-1 grep -A16 "external_services = {" /run/prosody/config/prosody.cfg.lua`)
sans penser que le champ `external_service_secret` qui précède ce bloc
contient le secret partagé avec coturn — visible en clair dans ma propre
sortie de commande, donc dans la conversation.

## Réaction

Traité tout de suite comme un secret compromis, selon la même règle que
l'incident du 2026-10-08 (application credential affichée en clair) :
révocation immédiate, pas d'attente. Le classificateur de permissions a
refusé que je régénère moi-même le secret (écriture dans un fichier de
secret) ; Adam a lancé la commande de rotation lui-même.

**Incident secondaire pendant la reprise** : après la rotation, j'ai lancé
le redéploiement en tâche de fond puis, pensant qu'il n'avançait pas, j'en
ai relancé un deuxième — puis un troisième — sans avoir vérifié que le
premier tournait encore. `ansible-playbook` partage apparemment la connexion
SSH (control socket) entre plusieurs exécutions simultanées vers le même
hôte : en tuant les doublons, j'ai fait planter un worker du premier
(« A worker was found in a dead state »), laissant la configuration à
moitié appliquée (le script de copie du certificat déployé, mais pas encore
la configuration de coturn ni son redémarrage). Rien de cassé : vérifié
avant de relancer que l'état du serveur correspondait bien à ce que les
journaux montraient (fichiers non modifiés depuis le run précédent),
puis une seule exécution, propre, jusqu'au bout.

## Corrections

- Nouveau secret généré par Adam, propagé à coturn (`turn.yml`) puis à
  Prosody (`visio.yml`). **Vérifié sans jamais l'afficher** : comparaison
  des empreintes (`sha256sum`) des deux côtés plutôt que de leur contenu —
  méthode maintenant dans `docs/runbooks/turn.md`.
- Règle ajoutée au runbook : ne jamais lancer deux `ansible-playbook` en
  même temps sur ce serveur.
- Règle pour moi : avant d'afficher le résultat d'une commande de
  vérification sur une configuration générée, vérifier qu'aucun champ du
  bloc affiché n'est un secret — au besoin, filtrer précisément la ligne
  utile plutôt que d'afficher tout un bloc par confort.

## Comprendre

Les deux incidents de cette intervention ont la même racine : vérifier vite
plutôt que vérifier juste. Afficher tout un bloc de configuration pour
« voir si c'est bien là » est plus rapide à écrire qu'un filtre précis, mais
un bloc de configuration contient souvent plus que ce qu'on voulait
vérifier. De même, relancer une commande qui « semble » bloquée est plus
rapide que de vérifier d'abord si elle tourne encore. Dans les deux cas, le
réflexe correct — déjà appris le 2026-10-08 pour le premier, maintenant pour
le second — est de vérifier l'état avant d'agir, pas après.