gilles
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>
34 lines
1.3 KiB
Markdown
34 lines
1.3 KiB
Markdown
# 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 `keyring` indique 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 `keyring` 4.x sépare davantage les composants de librairie, donc l'ajout Cargo doit être fait après choix précis entre `keyring-core` + store Secret Service ou une version `keyring` 3.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`.
|