Files
khadhroony-solana-project/deltas/0.2.5/pre.007.md
2026-08-19 18:08:01 +02:00

126 lines
4.5 KiB
Markdown

<!-- file: deltas/0.2.5/pre.007.md -->
<!-- version: 1 -->
# 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
```