Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8ba554306a0ac5191d39cc7d5820b4e5bc0f5e2e
khadhroony-solana-project/deltas/0.2.5/pre.001-fix.001.md

239 lines
7.6 KiB
Markdown
Raw Blame History

<!-- file: deltas/0.2.5/pre.001-fix.001.md -->
<!-- version: 1 -->
# 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 :
```text
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
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
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 :
```text
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` :
```text
.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` :
```text
workspace.package.version = "0.2.5-pre.1"
```
`Cargo.toml` reste inchangé.
## Fichiers modifiés
```text
ROADMAP.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md
```
Versions documentaires :
```text
ROADMAP.md 45 -> 46
002-FUNCTIONAL_RELEASE_SEQUENCE.md 45 -> 46
012-V0_2_5_WALLET_FOUNDATION_PLAN.md 3 -> 4
```
## Fichier ajouté
```text
deltas/0.2.5/pre.001-fix.001.md
```
## Fichiers volontairement inchangés
```text
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
```text
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.
Reference in New Issue View Git Blame Copy Permalink