Sasedev/khadhroony-solana-project
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

v0.2.5-pre.002

Browse Source
This commit is contained in:
SinuS von SifriduS
2026-08-19 09:56:01 +02:00
parent c2ccef3849
commit c97a8739ab
19 changed files with 1037 additions and 27 deletions
Download Patch File Download Diff File Expand all files Collapse all files

51
docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md
View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Plan `0.2.5` — Wallet foundation
@@ -77,7 +77,8 @@ Clarifications confirmées pendant la revue du gate :
27. **OWNER peut changer son propre password OWNER et le password VIEW**, sans connaître l'ancien password VIEW ; OWNER reste seul capable de l'administration metadata et des key slots au-delà du self-service de rotation VIEW ;
28. la keypair Solana est **immuable dans un wallet V1 après création/import**. V1 ne fournit pas d'opération de remplacement de keypair ; une autre keypair crée un autre wallet ;
29. les permissions/ACL du système de fichiers ne constituent **ni une garantie cryptographique ni une responsabilité de sécurité de `ksp-wallet-lib`**. Le contrat Wallet porte sur les capacités : sans OWNER, aucune signature Solana, aucun export secret, aucune écriture acceptée de Pubkey/alias/notes et aucune mutation OWNER-controlled ; la seule mutation volontairement accordée à VIEW est la rotation de son propre password ;
30. tout import produit un **nouveau `.kspwallet`** selon la sémantique no-clobber de `create`. Un import ne remplace, n'écrase et ne transforme jamais un `.kspwallet` existant.
30. tout import produit un **nouveau `.kspwallet`** selon la sémantique no-clobber de `create`. Un import ne remplace, n'écrase et ne transforme jamais un `.kspwallet` existant ;
31. `ksp-wallet-lib` ne possède aucun « répertoire Wallet par défaut » ni configuration correspondante. Les opérations de persistence reçoivent un chemin/répertoire explicite du caller ; une future application peut faire résoudre son propre défaut par Config puis transmettre le chemin à Wallet, sans créer de dépendance Wallet -> Config.
## 4. Réaudit de l'héritage bot2/bot3
@@ -368,16 +369,16 @@ Aucune dépendance ci-dessous n'est ajoutée dans `pre.001`. Ce sont les candida
### 8.1 Solana low-level
| Besoin | Crate publiée auditée | Décision candidate |
|------------------|--------------------------|--------------------------------------------------------|
| Pubkey | `solana-pubkey 4.3.0` | déjà workspace, conserver |
| keypair concret | `solana-keypair 3.1.2` | retenir, features minimales |
| interface signer | `solana-signer 3.0.1` | retenir si contrat public/impl l'exige |
| signature | `solana-signature 3.5.2` | dépendance directe seulement si le type public l'exige |
| Besoin | Crate publiée auditée | Décision candidate |
|------------------|--------------------------|---------------------------------------------------------------------------------------------|
| Pubkey | `solana-pubkey 4.3.0` | propriété Core ; Wallet consomme uniquement `ksp_core_lib::Pubkey`, sans dépendance directe |
| keypair concret | `solana-keypair 3.1.2` | retenir, features minimales |
| interface signer | `solana-signer 3.0.1` | retenir si contrat public/impl l'exige |
| signature | `solana-signature 3.5.2` | dépendance directe seulement si le type public l'exige |
`solana-keypair` fournit le keypair Ed25519, la conversion stricte depuis 64 octets, la signature, le format JSON de 64 entiers et une représentation Base58 complète. Aucun client RPC Solana n'est nécessaire.
La génération SDK récente définit `Pubkey` comme alias du type `Address`, mais l'écosystème a déjà connu des incompatibilités lorsque plusieurs générations de `solana-address` coexistent. `pre.002` doit donc prouver par compilation/cargo-tree que le `Pubkey` possédé par `ksp-core-lib` et le `Address/Pubkey` exposé par `solana-keypair` sont de la même génération avant de figer les signatures publiques Wallet. Aucun second type d'adresse KSP n'est introduit pour contourner un mismatch.
La génération SDK récente définit `Pubkey` comme alias du type `Address`, mais l'écosystème a déjà connu des incompatibilités lorsque plusieurs générations de `solana-address` coexistent. `pre.002` verrouille donc la surface publique Wallet sur **`ksp_core_lib::Pubkey` exclusivement** et n'ajoute aucune dépendance directe `solana-pubkey`. Lorsque `solana-keypair` sera réellement introduit, la tranche concernée devra prouver par compilation/cargo-tree que son `Address/Pubkey` est compatible avec la génération possédée par Core avant toute conversion interne. Aucun second type d'adresse KSP n'est introduit pour contourner un mismatch.
Un `cargo tree` est obligatoire lors de l'introduction réelle afin de contrôler les versions `ed25519-dalek`, `solana-signature`, `rand/getrandom` et éviter des duplications évitables.
@@ -412,7 +413,7 @@ AES-GCM-SIV apporte une meilleure tolérance à la réutilisation accidentelle d
### 8.5 Secret memory
`zeroize 1.9.0` est retenu. `secrecy` n'est pas ajouté tant qu'un besoin ergonomique concret n'est pas démontré ; des types KSP simples peuvent imposer eux-mêmes redaction/non-Clone et utiliser `Zeroize`/`Zeroizing`.
`zeroize 1.9.0` est retenu et devient la seule nouvelle dépendance tierce de `pre.002`, car les wrappers `ViewPassword` / `OwnerPassword` l’utilisent immédiatement pour leur nettoyage au `Drop`. `secrecy` n'est pas ajouté tant qu'un besoin ergonomique concret n'est pas démontré ; des types KSP simples imposent eux-mêmes redaction/non-Clone et utilisent `zeroize`.
Pour la clé admin Ed25519 distincte, `ed25519-dalek 3.0.0` est une candidate standard, mais son ajout direct est **conditionné au cargo-tree** de la tranche qui implémente l'authentification afin d'éviter une génération concurrente inutile avec celle déjà tirée par `solana-keypair`.
@@ -435,7 +436,7 @@ Candidates :
```text
base64 0.23.1 pour Base64url sans padding des champs binaires JSON
tempfile 3.27.0 pour temp files privés same-directory + persist/persist_noclobber
tempfile 3.27.0 pour temp files same-directory + persist/persist_noclobber
```
Elles ne sont ajoutées que lorsqu'elles sont réellement consommées.
@@ -766,10 +767,12 @@ La crate peut donc être utilisée depuis Tauri plus tard sans dépendre de Taur
### 14.1 Baseline portable
Le chemin de destination est toujours fourni explicitement par le caller ; Wallet ne lit aucune Config ni variable d'environnement pour choisir un répertoire par défaut.
Pour créer/remplacer un `.kspwallet` :
1. sérialiser complètement le nouvel état en mémoire bornée ;
2. créer un temp file privé **dans le même répertoire** que la destination ;
2. créer un temp file unique **dans le même répertoire** que la destination ;
3. écrire tout le contenu ;
4. `flush`/`sync_all` le temp file ;
5. publier avec une primitive no-clobber pour `create` ou replace pour administration ;
@@ -836,13 +839,13 @@ notes/alias par défaut
## 16. Logging
Cible KSP future proposée :
Le target principal Wallet est explicitement possédé par `src/constants.rs` conformément à `DEP-LOG-010` :
```text
ksp.wallet
pub(crate) const TRACING_TARGET: &str = "ksp-wallet-lib";
```
Via `ksp-logging-lib` uniquement.
Toutes les émissions passent par `ksp-logging-lib` uniquement. Wallet ne dépend jamais directement de `tracing` et n’utilise pas `env!("CARGO_PKG_NAME")` comme target.
Événements sûrs :
@@ -1065,9 +1068,15 @@ Une `fix` ou tranche supplémentaire est préférable à la suppression d'une ga
## 22. Dépendances candidates par tranche
Aucune ajoutée en `pre.001`.
`pre.001` n’ajoutait aucune dépendance. `pre.002` ajoute uniquement :
Liste de travail, à réauditer juste avant insertion sous `[workspace.dependencies]` :
```text
zeroize ^1.9
```
La dépendance est centralisée sous `[workspace.dependencies]` puis consommée avec `zeroize.workspace = true`. Elle est utilisée immédiatement par les wrappers de password ; aucune crate crypto/KDF/Solana supplémentaire n’est ajoutée par anticipation. La génération courante `zeroize 1.9.0` a été réauditée avant insertion.
Liste de travail restante, à réauditer juste avant insertion sous `[workspace.dependencies]` :
```text
argon2 ^0.5
@@ -1079,7 +1088,6 @@ solana-keypair ^3.1
solana-signer ^3.0 # si réellement nécessaire directement
solana-signature ^3.5 # seulement si le type public l'exige
tempfile ^3.27
zeroize ^1.9
```
Déjà présents et réutilisables :
@@ -1088,11 +1096,12 @@ Déjà présents et réutilisables :
serde
serde_json
tokio
solana-pubkey
ksp-core-lib
ksp-core-lib # propriétaire/réexport de Pubkey pour Wallet
ksp-logging-lib
```
`ksp-wallet-lib` ne déclare pas `solana-pubkey` : toute Pubkey publique ou interne du domaine Wallet passe par `ksp_core_lib::Pubkey`.
Non retenus nativement en V1 :
```text
@@ -1184,4 +1193,4 @@ Une future `format_version >= 2` pourra réétudier des facteurs/ancrages extern
## 26. Suite immédiate
`0.2.5-pre.002` crée seulement la foundation de `ksp-wallet-lib` : boundaries Cargo, types de capability/password/info, erreurs, façade logging et canaries architecturales. Le codec et la cryptographie du fichier restent à `pre.003+`.
`0.2.5-pre.003` est la suite immédiate : codec JSON strict, limites, DTOs d’enveloppe/key slots, transcript/AAD et première spécification `docs/formats/KSPWALLET_V1.md`. La cryptographie effective KDF/AEAD reste à `pre.004+`.