khadhroony-solana-project/deltas/0.2.5/pre.007.md

Delta 0.2.5-pre.007 — signing + administration + rotations VIEW/OWNER

Base

0.2.5-pre.6.fix.1

Version workspace cible :

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 :

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 :

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 :

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 :

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

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

v0.2.5-pre.007