# Delta `0.2.5-pre.007` — signing + administration + rotations VIEW/OWNER ## Base ```text 0.2.5-pre.6.fix.1 ``` Version workspace cible : ```text 0.2.5-pre.7 ``` ## Objectif Cette tranche complète l'administration native `.kspwallet` V1 au-dessus des primitives crypto `pre.004`, des capabilities in-memory `pre.005` et de la persistence `pre.006`, sans introduire Config, Transport, Tauri, Store, `WalletPolicy` ni secret externe. ## Implémentation ### Signature Solana OWNER `WalletOwner::sign(message)` produit une signature Ed25519 Solana de 64 octets sans exposer seed/keypair brute. La keypair reste encapsulée dans l'état OWNER et n'est pas réexportée via `ksp-core-lib`. ### Metadata OWNER OWNER peut : ```text update_alias add_note update_note delete_note ``` La Pubkey reste immutable en V1. Chaque mutation rechiffre les metadata avec un nonce neuf et resign l'état OWNER. Un note ID absent retourne `wallet.note_not_found`. ### Rotations credentials - VIEW peut changer uniquement son propre password VIEW ; - OWNER peut changer le password VIEW sans connaître l'ancien password VIEW ; - OWNER peut changer son propre password OWNER ; - une rotation VIEW simple conserve `slot_id` + `K_metadata` et laisse la `state_signature` inchangée conformément au transcript V1 ; - une rotation OWNER conserve `slot_id` + `K_owner_root`, puis resign l'état ; - aucune rotation de password ne change la keypair Solana. ### Révocation forte VIEW OWNER peut `disable_view` ou `recreate_view`. Ces opérations génèrent un nouveau `K_metadata`, rechiffrent les metadata, réécrivent `owner_control`, modifient le descripteur/slot VIEW et resignent l'état. `recreate_view` utilise un nouveau `slot_id` VIEW. ### Persistence administrative capability-bound Aucune API publique `replace(path, bytes)` n'est ajoutée. Les mutations stage le nouvel état en mémoire, persistent ensuite, puis mettent le handle à jour uniquement si la publication réussit. Le replacement crate-private vérifie avant publication — puis de nouveau juste avant le replace — que la destination courante : ```text est lisible dans la borne V1 se parse strictement possède une state_signature OWNER valide est sémantiquement égale à l'enveloppe authentifiée attendue par le handle ``` Un mauvais chemin ou un handle stale retourne `wallet.state_conflict`. Ce garde-fou empêche les overwrites silencieux dans le flux KSP mais n'est pas présenté comme un CAS filesystem portable/linéarisable : une fenêtre TOCTOU reste possible entre la dernière vérification et le remplacement selon la plateforme/filesystem. ## Dépendances Aucune nouvelle dépendance tierce. `tempfile 3.27.0` acquis en `pre.006` est réutilisé pour le temp file same-directory des remplacements administratifs. `solana-keypair` reste propriétaire de Wallet ; `ksp-core-lib` continue de réexporter uniquement `Pubkey` comme primitive Solana transversale. ## Canaris/tests ajoutés La tranche couvre notamment : ```text signature Solana déterministe et stable à travers rotation OWNER rotation VIEW self-service : ancien password rejeté, nouveau accepté rotation VIEW par OWNER sans ancien password VIEW alias/notes OWNER visibles après réouverture VIEW Pubkey/keypair invariantes à travers mutations/rotations strong disable/recreate VIEW : nouveau K_metadata + nouveau slot VIEW ancien password VIEW rejeté après recreate fault avant replacement : ancien fichier conservé replacement exige une destination fichier existante handle OWNER stale -> wallet.state_conflict mauvais état cible -> wallet.state_conflict public API canary signature 64 octets ``` ## Documentation Mise à jour : ```text docs/formats/KSPWALLET_V1.md docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md ROADMAP.md ``` La spécification V1 documente désormais les procédures signing/admin/rotations/révocation forte et les limites du replacement capability-bound sans modifier `format_version = 1`. ## Validation opérateur requise ```bash cargo fmt --all cargo check --workspace cargo clippy --workspace --all-targets cargo test -p ksp-wallet-lib cargo test --workspace cargo tree -p ksp-wallet-lib cargo tree -p ksp-wallet-lib -d ``` Le sandbox de préparation ne dispose pas du toolchain Cargo/Rust : ces validations n'y ont pas été exécutées et doivent être réalisées sur le workspace opérateur avant commit. ## Commit attendu ```text v0.2.5-pre.007 ```