08919752e3
Checkpoint multi-chantiers (arbre vert : tsc 0 erreur, 70 tests, build OK). - tâche 1.9 Phase 1 : schéma socle (machine_state/events/reports/raw_artifacts/ hardware/metrics + colonnes étendues) + wiring refresh/execute. Migration 0002. - tâche 1.9 Phase 2 : machine_credentials + machine_host_keys (non destructif, dual-read + backfill). Migration 0003. Fix séquence journal de migration. - tâche 2 : SJ-0 (types étendus rétro-compatibles, réducteur Docker, resolveTemplate), SJ-1 (update-analyze enrichi), SJ-2 (apply + diff dpkg + timeout inactivité SSH), SJ-3 (reboot vérifié boot_id). - WIP parallèle inclus : /api/capabilities, auth/apiTokens/apiClients, system metrics, scaffold app_rust, ajustements frontend. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1.3 KiB
1.3 KiB
Stockage du token API
Objectif : l'application locale ne doit pas stocker le token API en clair dans un fichier de configuration.
État actuel du scaffold :
--token: accepté pour test manuel ponctuel ;SYSTEM_UPDATE_TOKEN: accepté pour développement ;- trousseau système : prévu, pas encore activé dans
Cargo.toml.
Identité prévue dans le trousseau :
- service :
system-update; - compte :
api-token.
Choix technique à finaliser :
- la documentation actuelle de
keyringindique que Linux dispose de plusieurs magasins possibles, dont keyutils et Secret Service ; - pour une app GNOME, Secret Service est le choix naturel ;
- l'écosystème
keyring4.x sépare davantage les composants de librairie, donc l'ajout Cargo doit être fait après choix précis entrekeyring-core+ store Secret Service ou une versionkeyring3.x encore centrée librairie.
Références :
- https://docs.rs/keyring/latest/keyring/
- https://docs.rs/crate/keyring/latest
- https://github.com/open-source-cooperative/keyring-rs/wiki/Keyring-Core
Règle de sécurité :
- token jamais loggé ;
- token jamais écrit dans les rapports ;
- token affiché uniquement sous forme de préfixe côté backend ;
- révocation possible côté backend via
api_clients.revoked_at.