Épic — rework secrets côté CLI : providers (keychain/sops) + lookup scopé

[AlexisLaporte]

Contexte

Aujourd'hui oto config provider secrets <file|scaleway> propose deux providers + fallback env vars. Côté usage interne Otomata on utilise aussi SOPS (repo otomata-tech/secrets), mais ce n'est pas exposé comme un provider de premier ordre dans la CLI.

Pour la distribution publique de oto-cli, le défaut "fichier .env" est universel mais peu sécurisé (secrets en clair sur disque). Les CLIs grand public (gh, aws-cli, pip, docker) utilisent le keychain OS comme défaut : macOS Keychain, GNOME Keyring / libsecret sur Linux desktop, Credential Manager sur Windows. Lib Python standard : keyring.

Proposition

Liste cible des providers :

Provider	Cible	Notes
env (implicite, toujours top-prio)	tous	déjà là
keychain	desktop solo (Mac, Linux desktop, Windows)	à ajouter, défaut recommandé pour fresh install
file	serveur, CI, fallback	.otomata/secrets.env plat — déjà là, à documenter clairement
sops	équipes, multi-machine via repo Git	à ajouter explicitement (aujourd'hui implicite/maison)
scaleway	déploiements prod Otomata	déjà là

TODO

• Ajouter provider keychain via la lib keyring (extra optionnel pipx install oto-cli[keychain])
• Ajouter provider sops explicite (lit ~/.otomata/secrets/secrets.yaml, déchiffre via sops)
• Détection auto au premier run : si keychain dispo → suggérer ; sinon file
• Doc README : section "Secrets" qui présente les 4 options + quand utiliser laquelle
• Préciser : le repo otomata-tech/secrets est un workflow Otomata interne, pas une dépendance de la CLI

Limites connues

• Keychain inutilisable sur serveur headless (pas de session déverrouillée) → toujours offrir file en alternative
• Keychain pas multi-machine → SOPS reste la bonne réponse pour ce cas

[AlexisLaporte]

Update — multi-file SOPS layout is now in place

Migration pass → SOPS terminée. Le repo otomata-tech/secrets contient maintenant :

secrets/
├── secrets.yaml         # transverse Otomata (44 keys)
├── tuls.yaml            # host tuls.me (8 keys)
├── legacy.yaml          # orphelins préservés (5 keys)
├── missions/*.yaml      # 9 fichiers — par mission/client
└── projects/*.yaml      # 2 fichiers — projets internes Otomata

Côté CLI, le provider sops a été adapté :

• Nouvelle option config sops_dir (préférée) — walk récursif de tous les *.yaml, merge en dict plat avec warning sur duplicats.
• sops_file (legacy) toujours supporté — mono-fichier.
• Auto-détection du dir si rien n'est configuré.

Limites restantes (à traiter dans cette issue)

1. Lookup à plat : get_secret("KEY") cherche dans tous les fichiers — pas de scoping. Si deux missions ont une clé homonyme (API_KEY), conflit.
   → Considérer un get_secret("KEY", scope="roundtable") qui lit missions/roundtable.yaml directement.

2. keychain toujours pas implémenté — provider à ajouter (OS-native, lib keyring).

3. Doc README à mettre à jour pour présenter les 3 options : env, keychain (à venir), sops (avec layout multi-fichiers), scaleway (legacy).

[AlexisLaporte]

Fusion d'otomata#19 (arbitrage backlog 2026-06-12). Cette issue devient l'épic du rework secrets côté CLI. Périmètre : le vault est hors oto (AlexisLaporte/secrets, perso) — mais le code de résolution vit dans oto-core (oto.config.get_secret, sops_secrets.py) et l'UX dans oto-cli. Deux volets :

Volet A — providers (corps de cette issue)

keychain OS via keyring, provider sops explicite, détection au premier run, doc README.

Volet B — lookup scopé (ex-otomata#19)

La résolution sops merge tous les fichiers du vault (secrets.yaml, tuls.yaml, legacy.yaml, missions/*.yaml, projects/*.yaml) dans un dict plat :

• 11 clés en collision constatées (DATABASE_URL dans 5 fichiers projets, DB_*, LOGTO_M2M_*) ; depuis oto-core 2d011ff elles lèvent AmbiguousSecretError — honnête mais inadressables via l'API.
• Pas de notion de scope dans l'API alors que le layout du vault est scopé ; consommation des fichiers scopés = contournement (sops -d direct).
• Coût : chaque process CLI décrypte ~20 fichiers via subprocess pour lire 1 clé ; un fichier indécryptable casse tout.

Pistes : get_secret(name, scope="projects/x") + défaut = fichiers racine seulement ; scope ambiant (OTO_SECRET_SCOPE / config locale) ; lazy-load par fichier ; lint anti-collision côté vault.

Repos touchés : oto-core (résolution), oto-cli (UX), vault perso (layout + lint).

[AlexisLaporte]

Fusion d'otomata#2 (arbitrage backlog 2026-06-12) — Volet C : sélection de périmètre (multi-stores).

Besoin : empêcher qu'un oto anthropic lancé depuis un projet 321FOUNDED consomme la clé Otomata (et inversement, ne pas exposer les secrets transverses dans un contexte client).

Proposition d'origine (pré-relocation du vault) : --store <x> global Typer / env OTO_STORE, un fichier SOPS par périmètre avec ses propres recipients age, pas de cascade automatique, erreur explicite si store absent.

État 2026-06 : le layout multi-fichiers du vault (missions/*.yaml, projects/*.yaml) a déjà matérialisé les « stores » côté données. Ce volet = l'UX de sélection (flag/env, voire scope ambiant par cwd en suivi), qui s'appuie sur le lookup scopé du volet B — même mécanique de résolution, deux surfaces.

Reste spécifique à C : recipients age distincts par périmètre (le vault actuel partage les mêmes), et la migration des clés 321 (pass 321/) vers leur fichier scopé.

[AlexisLaporte]

Fermée : l'épic vise un composant qu'on a explicitement rétrogradé.

Depuis son ouverture (19/05), la CLI est passée au statut de fallback local basse priorité — la surface canonique est le connecteur MCP, et la CLI ne sert plus que de repli. Une refonte du stockage de ses secrets (trousseau du système en défaut, providers de premier ordre, résolution scopée) est un chantier de produit distribué : il suppose une distribution publique qui n'est pas la trajectoire actuelle.

Ce qui reste vrai et mérite d'être noté : le défaut « fichier .env en clair sur disque » est le point faible du modèle actuel, et les CLI grand public utilisent toutes le trousseau du système. Le jour où la CLI redevient un produit qu'on distribue, c'est le premier sujet à rouvrir — pas avant.

La CLI continue par ailleurs de vivre normalement (version 1.7.0) : ce n'est pas un abandon, c'est le refus d'un chantier de fond sur un composant de repli.