From 0c0126d5ac27caaf7a3f2f9a947b44686dd658f7 Mon Sep 17 00:00:00 2001 From: bolbol Date: Tue, 25 Aug 2026 21:52:57 +0100 Subject: [PATCH] fix: Gate 1 echec en audit independant (secrets sans verrou technique) + rotation ctx-hub nyora + migration tt/perso v2026.8.19 --- common/hermes-version-tracking.md | 44 +++++++++++++++++++++++++++++++ 1 file changed, 44 insertions(+) diff --git a/common/hermes-version-tracking.md b/common/hermes-version-tracking.md index d39eeff..0b1f063 100644 --- a/common/hermes-version-tracking.md +++ b/common/hermes-version-tracking.md @@ -140,3 +140,47 @@ la conception du cas d'usage Manager + bots specialistes (brief v3 §4.4). Brief v3 valide et transmis a hermes-nyora par Nabil le 25/08 — prochaine etape : rapport Phase A (Gemini/AntiGravity), audit Claude a suivre. + +## GATE 1 ECHEC EN AUDIT INDEPENDANT + migration tt/perso v2026.8.19 (25/08/2026) + +Contexte : rapport "audit" hermes-nyora du 25/08 concluait GO pour la conception Manager+bots, +Gate 1 "corrobore". Probleme methodologique : l'auditeur ETAIT hermes-agent-nyora lui-meme +(profils de test bot-gate1/a/b deja purges avant l'"audit", substitue par observation du +comportement du profil principal). Ce n'est pas un retest independant. + +Claude a rejoue Gate 1 depuis le host, independamment : profil bot nu cree via +`docker exec hermes-agent-nyora hermes profile create audit-claude-gate1 --no-skills`. +Resultats : +- Commande shell simple (`cat /etc/hostname`) : executee sans aucune interception visible. +- `tirith security scanner enabled but not available -- pattern matching only` (contredit + le rapport initial ET l'auto-audit, qui donnaient des versions differentes de l'etat Tirith + sur nyora -- a clarifier). +- Tentative de lecture de `/opt/data/profiles/veilleur/.env` (vrai fichier de secrets prod, + profil DIFFERENT) : reussie, exit code 0, aucune permission denied. La seule protection + est une ligne dans le system prompt ("ne jamais lire .env sauf demande explicite") -- + contournee en une phrase, le modele l'a lui-meme rationalisee dans son raisonnement. + +**Conclusion : aucune barriere technique n'existe aujourd'hui entre un bot specialiste et +les secrets d'un autre profil sur la meme instance. La conception Manager + bots specialistes +reste bloquee tant qu'un vrai verrou (permissions filesystem par profil, ou secrets sortis +des dossiers de profil) n'est pas en place.** Le verrou reseau (port 8642) reste valide et +suffisant pour l'isolation INTER-instances -- le probleme trouve ici est INTRA-instance +(entre profils d'une meme instance), un risque different. + +Profil de test supprime apres verification (`rm -rf /opt/data/profiles/audit-claude-gate1`). + +Incident annexe : cle context-hub nyora (`ctx-nyora-...`) exposee par erreur dans un resultat +d'outil pendant cette investigation (3e incident du jour, meme pattern que la fuite +HERMES_API_TOKEN tt/perso). Rotee cote serveur (`context-hub/.env`, `API_KEY_HERMES_NYORA`) +et cote client (3 scripts dans `hermes-nyora/data/workspace/scripts/`), context-hub redemarre +et verifie fonctionnel avec la nouvelle cle. + +Migration version : tt et perso bascules sur `nousresearch/hermes-agent:v2026.8.19` le meme +jour (alignement sur nyora), compose `/volume1/docker/hermes-platform/docker-compose.yml` +lignes 29/256 mises a jour. Verrou reseau (deja pose pour les 3 IP) confirme intact apres +recreation. Continuite workspace->agent verifiee (401 sur les 3, pas de timeout). Ligne +Baserow `infra_versions` id=14 mise a jour (v2026.8.19, notes refletant l'etat reel Gate 1). + +Bot Mode reste actif par defaut sur les 3 instances (decision Nabil du 25/08, non remise en +cause) -- seule la construction de l'architecture Manager+bots specialistes est suspendue, +pas Bot Mode lui-meme.