Files
khadhroony-bot3/ks-wallet/README.md
2026-08-11 15:15:03 +02:00

4.8 KiB
Raw Permalink Blame History

ks-wallet

ks-wallet fournit la frontière wallet Solana générale du workspace Khadhroony.

Contrat 0.5.2

ks-wallet constitue la frontière générale de stockage, authentification et signature des wallets Solana du workspace. Le format persistant recommandé est .kswallet; le JSON Solana historique reste une compatibilité legacy et une source d'import.

La crate fournit actuellement :

  • alias validés ;
  • identité publique minimale WalletIdentity sans chemin local ;
  • WalletManager pour scanner/lookup les .kswallet structurellement valides du répertoire configuré ;
  • inspection explicite d'un .kswallet sélectionné hors du store via un handle opaque ;
  • décodage et encodage v1 stricts avec identité publique déclarée, paramètres KDF/AEAD bornés et payload keypair de taille exacte ;
  • création persistante native avec WalletManager::create() et publication atomique/no-clobber ;
  • ouverture authentifiée par alias avec WalletManager::unlock() ;
  • ouverture d'un fichier explicitement sélectionné avec WalletManager::unlock_file() sans l'enregistrer dans le store ;
  • changement du mot de passe avec WalletManager::change_password() en conservant exactement la même keypair/pubkey ;
  • migration non destructive de <alias>.json vers <alias>.kswallet avec WalletManager::migrate_legacy() ;
  • inspection sûre d'un fichier de transfert via inspect_transfer_file(), qui valide le keypair sans l'importer et ne retourne que sa pubkey publique ;
  • inventaire stable des formats via WalletTransferFormat::supported() avec code, libellé et extension conventionnelle ;
  • import de fichiers secrets avec WalletManager::import_file() en SolanaCliJson ou SolanaPrivateKeyBase58 ;
  • export de fichiers secrets avec WalletManager::export_file(), uniquement après authentification du mot de passe du .kswallet ;
  • refus des collisions dalias et de pubkey lors dun import ;
  • publication dexport privée, atomique et sans écrasement silencieux ;
  • WalletPassword, frontière possédée, non clonable et redacted pour une opération ;
  • UnlockedWallet, capacité de signature authentifiée non clonable et sans getter des bytes privés ;
  • wallet temporaire en mémoire ;
  • stockage legacy local JSON d'un keypair Solana ;
  • création exclusive avec refus d'écrasement et reprise des courses load_or_create ;
  • résumé/identité sans matériau cryptographique secret ni chemin local ;
  • accès au trait Signer sans exposition des octets ;
  • signature de messages ;
  • permissions Unix privées et contrôles de fichiers ;
  • effacement des buffers secrets temporaires utilisés lors de la lecture ou écriture.

La persistance legacy écrit encore directement le contenu dans le chemin final : elle n'est pas une publication atomique crash-safe par fichier temporaire + renommage.

Format natif et compatibilité

Le format .kswallet utilise Argon2id v19 pour la dérivation depuis le mot de passe et XChaCha20-Poly1305 pour le chiffrement authentifié. Le layout normatif est documenté dans ../docs/NATIVE_FORMAT.md. Le payload secret v1 est exactement la keypair Solana brute de 64 octets ; le header, l'alias, le sel et le nonce sont authentifiés comme AAD avant qu'une capacité UnlockedWallet puisse être produite. Changer le mot de passe ne change jamais la keypair/pubkey.

Le scan automatique reste strictement borné au répertoire fourni à WalletManager. Un programme peut inspecter explicitement un autre .kswallet puis l'ouvrir avec unlock_file() sans modifier le store. Les erreurs, logs et Debug du store JSON legacy ne projettent plus ses chemins locaux.

Relations

ks-wallet possède et gère le wallet. Les exécuteurs et ks-lib doivent dépendre d'une capacité de signature, pas du format de stockage ni des octets privés.

ks-config peut sélectionner un alias ou une identité non sensible, mais ne stocke aucun mot de passe ni matériau secret.

ks-wallet-demo-scenarios consomme uniquement lAPI publique de ks-wallet pour orchestrer les validations intégrées du cycle de vie et, ultérieurement, des formats de transfert. Cette crate de scénarios ne fait pas partie de la frontière de stockage ou de chiffrement.

Une application desktop doit projeter les informations autorisées dans ses propres DTO Tauri ; ks-wallet ne réintroduit pas TS-RS.

Documentation