Supporter des secrets structurés et des politiques de backend #4

New issue

Closed

opened 2026-04-13 14:35:44 +00:00 by thibaud-lclr · 0 comments

thibaud-lclr commented

2026-04-13 14:35:44 +00:00

(Migrated from gitea.lclr.dev)

Le framework ne stocke aujourd’hui que des secrets de type chaîne, alors que email-mcp a besoin d’un credential structuré (host, username, password) et de contraintes de backend plus strictes.

Objectif : étendre secretstore pour supporter des objets sérialisés et une politique de backend explicite.

À couvrir :

stockage de secrets typés via codec ou helper JSON
backends configurables : auto, kwallet-only, keyring-any, env-only
erreurs plus explicites quand le backend requis n’est pas disponible
conservation d’une API simple pour le cas courant string

Critères d’acceptation :

email-mcp peut réutiliser le framework sans perdre son besoin de contrôle sur KWallet
le cas simple type token API reste trivial à implémenter

Le framework ne stocke aujourd’hui que des secrets de type chaîne, alors que `email-mcp` a besoin d’un credential structuré (`host`, `username`, `password`) et de contraintes de backend plus strictes. Objectif : étendre `secretstore` pour supporter des objets sérialisés et une politique de backend explicite. À couvrir : - stockage de secrets typés via codec ou helper JSON - backends configurables : `auto`, `kwallet-only`, `keyring-any`, `env-only` - erreurs plus explicites quand le backend requis n’est pas disponible - conservation d’une API simple pour le cas courant `string` Critères d’acceptation : - `email-mcp` peut réutiliser le framework sans perdre son besoin de contrôle sur KWallet - le cas simple type token API reste trivial à implémenter