khadhroony-solana-project/deltas/0.2.5/pre.001-fix.001.md

Delta 0.2.5-pre.001-fix.001 — correction des capacités VIEW/OWNER et du modèle d'authentification

Base requise

Ce fix s'applique après :

0.2.5-pre.001
workspace.package.version = "0.2.5-pre.1"

Le delta historique deltas/0.2.5/pre.001.md reste inchangé.

Type de livraison

ksp-general-0.2.5-pre.001-fix.001.zip

La livraison reste purement documentaire du point de vue Cargo, mais elle modifie ROADMAP.md à la racine ; conformément à VER-ARCHIVE-001, le paquet est donc de type general et non doc.

Motif du fix

Deux corrections sont nécessaires avant pre.002.

1. Identifiant de livraison

La correction postérieure à pre.001 ne doit pas réémettre silencieusement ksp-general-0.2.5-pre.001.zip. Conformément à VER-ID-003, VER-DELTA-003 et VER-DELTA-007, elle devient une livraison distincte :

0.2.5-pre.001-fix.001

2. Matrice exacte des capacités

Le plan précédent formulait trop largement VIEW comme incapable de toute mutation persistante. Le contrat fonctionnel attendu est plus précis :

VIEW
    lire Pubkey / alias / notes
    changer uniquement son propre password VIEW

VIEW -X-> signer
VIEW -X-> exporter le secret
VIEW -X-> modifier Pubkey / alias / notes
VIEW -X-> changer le password OWNER
VIEW -X-> activer/désactiver/recréer VIEW
VIEW -X-> modifier le slot OWNER ou l'état OWNER-controlled

OWNER
    tout ce que VIEW peut lire
    signer
    exporter via adapter explicitement OWNER-only
    modifier alias / notes
    changer son propre password OWNER
    changer le password VIEW sans connaître l'ancien password VIEW
    désactiver/recréer VIEW
    effectuer une révocation VIEW forte par rekey metadata

La keypair Solana reste immuable dans un .kspwallet V1 après création/import.

Correction du modèle cryptographique VIEW

La correction de capability impose une correction réelle du modèle d'authentification : si VIEW doit pouvoir changer son propre password sans OWNER, les champs de protection de son slot ne peuvent pas tous être couverts par une signature qui exige la clé privée d'administration OWNER à chaque réécriture.

Le plan sépare donc désormais :

État OWNER-controlled

Authentifié par state_signature Ed25519 OWNER :

magic / format_version / autorité de format
slot OWNER et sa protection
owner-control
metadata chiffrées
secret chiffré
descripteur stable VIEW
activation/désactivation VIEW
identité/rôle du slot VIEW
versions/algorithmes OWNER-controlled

Sans OWNER, cet état ne peut pas être modifié sous l'autorité courante du wallet.

Champs self-service du slot VIEW

Le slot VIEW possède un descripteur stable OWNER-signed. Seuls ses champs de protection courants sont rotatables par VIEW :

paramètres Argon2id VIEW autorisés par V1
salt VIEW
nonce/ciphertext du wrapping AEAD VIEW

Ils rewrappent la même K_metadata et sont liés par AAD au wallet, au rôle VIEW et au descripteur de slot OWNER-signed.

Un VIEW authentifié peut donc :

ancien password VIEW
    -> déverrouiller K_metadata
    -> choisir nouveau password VIEW
    -> nouveaux KDF/salt/KEK
    -> rewrap de la même K_metadata
    -> même descripteur VIEW

Il ne peut pas transformer cette opération en écriture de metadata, changement de OWNER, désactivation de VIEW ou remplacement de keypair.

Rotation et révocation

La distinction est désormais explicite.

Rotation VIEW par VIEW

• ne requiert pas OWNER ;
• ne modifie que le credential du slot VIEW courant ;
• conserve K_metadata, Pubkey, alias, notes et keypair ;
• l'ancien password ne déverrouille plus le slot courant ;
• ce n'est pas une révocation forte d'un ancien détenteur ayant conservé une ancienne copie ou déjà extrait K_metadata.

Rotation VIEW par OWNER

• ne requiert pas l'ancien password VIEW ;
• OWNER récupère K_metadata via owner-control ;
• crée un nouveau wrapping du slot VIEW avec le nouveau password ;
• conserve l'identité/keypair et les metadata.

Révocation VIEW forte par OWNER

• génère une nouvelle K_metadata ;
• rechiffre les metadata ;
• met à jour owner-control ;
• recrée/supprime le slot VIEW selon l'opération ;
• retire à une ancienne K_metadata l'accès aux futurs états metadata, sous réserve de la limite déjà documentée des anciennes copies/rollbacks.

Rotation OWNER

• OWNER peut changer son propre password ;
• rewrap K_owner_root avec de nouveaux KDF/salt/KEK ;
• renouvelle l'authentification OWNER correspondante ;
• ne change jamais la keypair Solana.

Invariants de sécurité conservés

La correction ne réduit aucune des garanties centrales de 0.2.5 :

.kspwallet V1 reste entièrement autonome
aucun facteur externe requis
Pubkey/alias/notes cachés wallet verrouillé
VIEW ne matérialise jamais le secret Solana
VIEW ne signe jamais
VIEW n'exporte jamais le secret
VIEW ne modifie jamais Pubkey/alias/notes
VIEW ne change jamais OWNER
OWNER reste indépendant de VIEW
OWNER peut gérer VIEW sans ancien password VIEW
import => nouveau .kspwallet no-clobber
keypair V1 immuable après création/import
spec multi-langages + vecteurs publics restent obligatoires

Les permissions/ACL OS restent hors du threat model Wallet.

Version Cargo

Ce fix est documentaire et ne modifie aucun fichier consommé par le build/runtime. Conformément à VER-ID-008 :

workspace.package.version = "0.2.5-pre.1"

Cargo.toml reste inchangé.

Fichiers modifiés

ROADMAP.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md

Versions documentaires :

ROADMAP.md                                      45 -> 46
002-FUNCTIONAL_RELEASE_SEQUENCE.md             45 -> 46
012-V0_2_5_WALLET_FOUNDATION_PLAN.md            3 -> 4

Fichier ajouté

deltas/0.2.5/pre.001-fix.001.md

Fichiers volontairement inchangés

Cargo.toml
CHANGELOG.md
deltas/0.2.5/pre.001.md
docs/000-README.md
docs/plans/000-README.md
crates/**

Validations exécutées

• relecture de VERSION_WORKFLOW.md, notamment VER-ID-003, VER-ID-008, VER-DELTA-003, VER-DELTA-007 et VER-ARCHIVE-001..004 ;
• vérification que le delta historique pre.001.md n'est pas modifié ;
• vérification que Cargo.toml reste identique à pre.001 ;
• vérification de la matrice VIEW/OWNER dans le plan, la séquence fonctionnelle et le roadmap ;
• vérification que le transcript OWNER exclut seulement les paramètres Argon2id VIEW autorisés, le salt et le nonce/ciphertext de wrapping du slot VIEW et conserve un descripteur VIEW OWNER-signed ;
• vérification que VIEW ne reçoit aucune API de mutation metadata, signature, export secret ou administration OWNER ;
• vérification que OWNER peut changer les passwords OWNER et VIEW ;
• vérification que l'import reste une création no-clobber d'un nouveau .kspwallet ;
• vérification que les ACL/permissions OS restent hors des garanties Wallet.

Validations Cargo

Aucune source Rust, dépendance, configuration runtime ou version Cargo n'est modifiée par ce fix. Les validations Cargo ne sont donc pas revendiquées comme nouvelles validations de cette livraison.

Commit attendu

v0.2.5-pre.001-fix.001

Suite

Après application/validation de ce fix, 0.2.5-pre.002 peut créer la foundation de ksp-wallet-lib en matérialisant dès l'API les capacités corrigées : VIEW lecture metadata + rotation de son seul password, OWNER administration complète + rotations OWNER/VIEW, sans codec/chiffrement lourd avant les tranches prévues.