v0.2.5-pre.010

This commit is contained in:
2026-08-20 09:58:14 +02:00
parent e91bf36e9e
commit 5bf9651038
15 changed files with 1363 additions and 43 deletions

File diff suppressed because one or more lines are too long

View File

@@ -1,5 +1,5 @@
<!-- file: docs/architecture/005-DEPENDENCY_GRAPH.md -->
<!-- version: 10 -->
<!-- version: 11 -->
# Graphe de dépendances KSP
@@ -131,17 +131,28 @@ La première surface est un reader de prix ; metadata HTTP/IPFS/Arweave et autre
```text
ksp-wallet-lib
-> ksp-core-lib
-> ksp-logging-lib
-> low-level crypto/key primitives explicitement retenues
-> ksp-core-lib # Pubkey/Error/Result
-> ksp-logging-lib # observabilité KSP
-> argon2 / chacha20poly1305 # KDF + AEAD
-> getrandom / zeroize # CSPRNG + secret memory
-> ed25519-dalek # autorité d'état OWNER
-> solana-keypair # keypair Solana encapsulée
-> serde / serde_json # wire JSON V1
-> tempfile / tokio # persistence + spawn_blocking
```
`ksp-core-lib::Pubkey` reste le type public transversal. `solana-keypair` est volontairement possédée directement par Wallet : elle contient le secret et la capacité de signature, n'est pas réexportée et n'est pas remontée dans Core par anticipation.
Interdictions :
```text
ksp-wallet-lib -X-> ksp-config-lib
ksp-wallet-lib -X-> ksp-onchain-transport-lib
ksp-wallet-lib -X-> ksp-execution-policy-api
ksp-wallet-lib -X-> Tauri / Store
ksp-wallet-lib -X-> tracing direct / std::env
ksp-wallet-lib -X-> solana-pubkey direct
ksp-wallet-lib -X-> solana-signer / solana-signature direct
```
Le Wallet stocke/ouvre/signe. Il ne décide pas si une dépense est autorisée.
@@ -377,7 +388,7 @@ ksp-app-wallet-desk
-> ksp-logging-lib
```
L'app compose ; elle ne déplace pas Config/Wallet/Transport dans Tauri.
L'app compose ; elle ne déplace pas Config/Wallet/Transport dans Tauri. Les handles `WalletView`/`WalletOwner` restent côté Rust, et le frontend ne reçoit que des DTOs sûrs. Config peut fournir la racine Wallet et le profil Transport ; les passwords et le secret Solana ne deviennent jamais des valeurs Config.
## Price Desk

View File

@@ -1,5 +1,5 @@
<!-- file: docs/formats/000-README.md -->
<!-- version: 4 -->
<!-- version: 5 -->
# Formats KSP
@@ -9,4 +9,4 @@ Une spécification de format décrit le wire exact, les encodages, les limites,
## Formats actifs
- [`KSPWALLET_V1.md`](KSPWALLET_V1.md) — spécification du format natif autonome `.kspwallet` V1. `0.2.5-pre.003` fige l'enveloppe/wire et les transcripts/AAD, `pre.004` ajoute Argon2id/XChaCha20-Poly1305/CSPRNG OS, `pre.005` fixe les payloads plaintext, le profil de création KSP calibré, l'autorité Ed25519 OWNER et le vecteur complet, `pre.006``pre.008` matérialisent persistence/administration/transfert, et `pre.009` clôt l'audit adversarial/interoperabilité/compliance avant la documentation finale.
- [`KSPWALLET_V1.md`](KSPWALLET_V1.md) — spécification du format natif autonome `.kspwallet` V1. `0.2.5-pre.003` fige l'enveloppe/wire et les transcripts/AAD, `pre.004` ajoute Argon2id/XChaCha20-Poly1305/CSPRNG OS, `pre.005` fixe les payloads plaintext, le profil de création KSP calibré, l'autorité Ed25519 OWNER et le vecteur complet, `pre.006``pre.008` matérialisent persistence/administration/transfert, `pre.009` ferme l'audit adversarial/interoperabilité/compliance et `pre.010` synchronise la documentation finale sans modifier le wire V1.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/formats/KSPWALLET_V1.md -->
<!-- version: 7 -->
<!-- version: 9 -->
# `.kspwallet` V1 — spécification du format natif Wallet KSP
@@ -20,7 +20,7 @@ AAD des compartiments owner-control / metadata / secret
règles unknown-field / unknown-version
```
`0.2.5-pre.004` ajoute les primitives KDF/AEAD normatives et un premier vecteur cryptographique public. `0.2.5-pre.005` fixe les payloads plaintext V1, l'autorité Ed25519 OWNER, les procédures de création et d'ouverture VIEW/OWNER, le profil de création KSP issu du benchmark opérateur et un vecteur `.kspwallet` complet généré indépendamment du code Rust. `0.2.5-pre.006` matérialise la persistence filesystem bornée et la création no-clobber. `0.2.5-pre.007` matérialise la signature Solana OWNER, l'administration des metadata, les rotations OWNER/VIEW, la révocation forte VIEW et leur remplacement filesystem capability-bound. `0.2.5-pre.008` matérialise les adapters Solana CLI JSON et Base58 complet, leur inspection sûre, l'import no-clobber vers un nouveau `.kspwallet` et l'export secret OWNER explicite. Toute évolution qui modifie un élément déjà déclaré **figé** par cette spécification exige une évolution explicitement tracée avant la release stable ; après publication de V1, une incompatibilité de wire exige un nouveau `format_version`.
`0.2.5-pre.004` ajoute les primitives KDF/AEAD normatives et un premier vecteur cryptographique public. `0.2.5-pre.005` fixe les payloads plaintext V1, l'autorité Ed25519 OWNER, les procédures de création et d'ouverture VIEW/OWNER, le profil de création KSP issu du benchmark opérateur et un vecteur `.kspwallet` complet généré indépendamment du code Rust. `0.2.5-pre.006` matérialise la persistence filesystem bornée et la création no-clobber. `0.2.5-pre.007` matérialise la signature Solana OWNER, l'administration des metadata, les rotations OWNER/VIEW, la révocation forte VIEW et leur remplacement filesystem capability-bound. `0.2.5-pre.008` matérialise les adapters Solana CLI JSON et Base58 complet, leur inspection sûre, l'import no-clobber vers un nouveau `.kspwallet` et l'export secret OWNER explicite. `pre.009` ferme l'audit adversarial/interoperability/compliance et `pre.010` synchronise la documentation de clôture sans modifier le wire ni les primitives. Toute évolution qui modifie un élément déclaré **figé** par cette spécification exige une évolution explicitement tracée avant publication stable ; après publication de V1, une incompatibilité de wire exige un nouveau `format_version`.
Le but final est qu'une implémentation indépendante en Rust, Python, Go, C/C++, Java ou autre puisse créer, parser, vérifier et ouvrir un `.kspwallet` sans lire le code source de `ksp-wallet-lib`.
@@ -663,18 +663,19 @@ round-trip du codec
Le premier vecteur cryptographique public KDF+wrapping est ajouté par `pre.004`. `pre.005` ajoute en plus un `.kspwallet` complet cryptographiquement valide et ses métadonnées de contrôle test-only, décrits en section 22.
## 19. Invariants encore à compléter sans modifier le wire figé
## 19. État de matérialisation avant publication stable
Les opérations autour du wire V1 sont désormais matérialisées jusqu'aux adapters de transfert :
Toutes les opérations V1 prévues par `0.2.5` sont matérialisées et auditées :
```text
pre.006 : persistence async/atomique/no-clobber acquis
pre.007 : signature Solana, metadata admin, rotations et révocation acquis
pre.008 : import/export Solana CLI JSON + Base58 complet acquis
pre.009+ : audit adversarial, compliance et documentation de clôture restant
pre.009 : audit adversarial/interoperability/compliance acquis
pre.010 : README/USAGE/spec/graphes/matrice de clôture acquis
```
Toute découverte imposant de modifier la grammaire, les payloads plaintext, les tags, l'ordre transcript ou les domain separators définis dans ce document doit être traitée explicitement avant la publication stable, jamais masquée par une tolérance du parseur.
`pre.010` ne modifie ni la grammaire, ni les payloads plaintext, ni les tags, ni l'ordre du transcript, ni les domain separators. Toute découverte imposant un tel changement après publication stable devra passer par une évolution explicitement versionnée ; une incompatibilité de wire V1 ne peut pas être introduite silencieusement sous `format_version = 1`.
## 20. Primitives cryptographiques effectives depuis `pre.004`
@@ -695,7 +696,7 @@ pepper = aucun
secret Argon2 externe = aucun
```
Un password vide est rejeté. V1 limite l'entrée password à 1024 octets UTF-8. Le KDF est une opération CPU/mémoire coûteuse ; les futures API async create/open l'exécuteront hors du thread executor conformément au plan Wallet.
Un password vide est rejeté. V1 limite l'entrée password à 1024 octets UTF-8. Le KDF est une opération CPU/mémoire coûteuse ; les API async create/open l'exécutent hors du thread executor via la boundary blocking documentée par Wallet.
Le default de création n'est **pas** déterminé par les defaults de la crate RustCrypto. Le benchmark opérateur a comparé :
@@ -1028,7 +1029,7 @@ Cette sonde n'est pas une dépendance KSP et n'est pas requise au runtime ; elle
Le profil de création `64 MiB / 3 / 1` est cohérent avec la seconde recommandation Argon2id de RFC 9106 pour les environnements contraints. Les paramètres restent sérialisés par slot afin que les futurs defaults puissent évoluer sans rendre les wallets existants illisibles. XChaCha20-Poly1305 conserve une clé 256 bits et un nonce 192 bits généré par le CSPRNG OS. Les signatures d'état utilisent Ed25519 au format 64 octets défini par RFC 8032.
Le graphe Cargo observé au gate `pre.008` conserve une seule génération `ed25519-dalek 2.2.0`, une seule `solana-address 2.7.0` et un unique parent KSP direct de `solana-keypair 3.1.2` : `ksp-wallet-lib`. Les doublons `digest 0.10/0.11`, `crypto-common 0.1/0.2`, `block-buffer 0.10/0.12`, `cpufeatures 0.2/0.3`, `getrandom 0.3/0.4`, `rand 0.9/0.10`, `rand_core 0.6/0.9/0.10`, `sha2 0.10/0.11` et `syn 2/3` sont transitoires et imposés par les générations actuellement consommées par RustCrypto, Solana et Logging ; KSP n'ajoute pas une deuxième dépendance directe pour les contourner.
Le graphe Cargo final observé au gate `pre.009` conserve une seule génération `ed25519-dalek 2.2.0`, une seule `solana-address 2.7.0` et un unique parent KSP direct de `solana-keypair 3.1.2` : `ksp-wallet-lib`. Les doublons `digest 0.10/0.11`, `crypto-common 0.1/0.2`, `block-buffer 0.10/0.12`, `cpufeatures 0.2/0.3`, `getrandom 0.3/0.4`, `rand 0.9/0.10`, `rand_core 0.6/0.9/0.10`, `sha2 0.10/0.11` et `syn 2/3` sont transitoires et imposés par les générations actuellement consommées par RustCrypto, Solana et Logging ; KSP n'ajoute pas une deuxième dépendance directe pour les contourner.
Limites explicitement conservées en V1 :
@@ -1038,3 +1039,11 @@ Limites explicitement conservées en V1 :
- la zeroization réduit les copies possédées mais ne constitue pas une preuve d'effacement physique de toute copie potentielle produite par le compilateur, l'OS ou le matériel ;
- aucune revendication de résistance side-channel supplémentaire au-delà des primitives et bibliothèques retenues.
## 26. Statut de clôture V1
À `0.2.5-pre.010`, cette spécification constitue la candidate finale du format `.kspwallet` V1. Les guides d'utilisation KSP sont [`../../crates/ksp-wallet-lib/README.md`](../../crates/ksp-wallet-lib/README.md) et [`../../crates/ksp-wallet-lib/USAGE.md`](../../crates/ksp-wallet-lib/USAGE.md) ; ils ne remplacent pas le présent document comme autorité normative du wire.
La matrice [`../validation/008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md`](../validation/008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md) enregistre les canaris adversariaux, la reproduction indépendante des vecteurs, les limites V1 et le checkpoint opérateur final de `pre.009`.
La publication stable `0.2.5` ne doit apporter aucune nouvelle décision cryptographique ou changement de wire. Elle publie la candidate validée ; toute correction fonctionnelle découverte avant le tag stable doit repasser par une tranche/fix explicite.

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md -->
<!-- version: 53 -->
<!-- version: 54 -->
# Séquence des releases fonctionnelles KSP
@@ -418,13 +418,15 @@ La release doit fournir `docs/formats/KSPWALLET_V1.md` comme spécification sép
`0.2.5-pre.006` ajoute la persistence native sans Config : `create_wallet_file_v1` reçoit un chemin explicite du caller et publie uniquement en no-clobber via un fichier temporaire créé dans le même répertoire, écrit puis `sync_all` avant `persist_noclobber`; `open_wallet_view_file_v1`, `open_wallet_owner_file_v1` et `inspect_locked_wallet_file_v1` effectuent une lecture bornée à la limite V1 avant de déléguer au parser/crypto acquis. Les opérations filesystem bloquantes sont isolées par `spawn_blocking`. Les tests couvrent destination existante, concurrence avec un seul gagnant, fault injection avant publication, cleanup ordinaire des temporaires et rejet d'un fichier surdimensionné. La synchronisation du répertoire parent est best-effort sur Unix et n'est pas transformée en garantie portable de crash-durability. Les ACL/permissions OS restent hors du modèle Wallet.
`0.2.5-pre.007` complète l'administration native capability-bound : OWNER signe des messages Solana sans getter secret, modifie alias/notes, change son password ou celui de VIEW et peut disable/recreate VIEW avec rekey metadata fort ; VIEW ne peut que tourner son propre credential en rewrappant le même `K_metadata`. Les mutations sont staged puis remplacent le fichier uniquement si la destination courante correspond encore à l'enveloppe authentifiée attendue ; un handle stale ou une mauvaise cible reçoit `wallet.state_conflict`. Ce garde-fou ne prétend pas fournir un CAS filesystem portable ni un anti-rollback externe. La keypair reste encapsulée dans Wallet et aucune nouvelle dépendance tierce n'est ajoutée. `pre.008` ajoute ensuite les adapters `solana_cli_json` et `solana_keypair_base58`, linspection sûre limitée à Pubkey+format, limport no-clobber vers un nouveau `.kspwallet` et lexport OWNER en mémoire/fichier. La source dimport reste inchangée, VIEW nexporte jamais, aucun `bs58` direct nest ajouté puisque `solana-keypair 3.1.2` possède déjà le codec Base58 complet. `pre.009` devient le prochain gate security/compliance.
`0.2.5-pre.007` complète l'administration native capability-bound : OWNER signe des messages Solana sans getter secret, modifie alias/notes, change son password ou celui de VIEW et peut disable/recreate VIEW avec rekey metadata fort ; VIEW ne peut que tourner son propre credential en rewrappant le même `K_metadata`. Les mutations sont staged puis remplacent le fichier uniquement si la destination courante correspond encore à l'enveloppe authentifiée attendue ; un handle stale ou une mauvaise cible reçoit `wallet.state_conflict`. Ce garde-fou ne prétend pas fournir un CAS filesystem portable ni un anti-rollback externe. La keypair reste encapsulée dans Wallet et aucune nouvelle dépendance tierce n'est ajoutée. `pre.008` ajoute ensuite les adapters `solana_cli_json` et `solana_keypair_base58`, linspection sûre limitée à Pubkey+format, limport no-clobber vers un nouveau `.kspwallet` et lexport OWNER en mémoire/fichier. La source dimport reste inchangée, VIEW nexporte jamais, aucun `bs58` direct nest ajouté puisque `solana-keypair 3.1.2` possède déjà le codec Base58 complet. `pre.009` ferme ensuite le gate adversarial/security/interoperability/compliance : canaris de tampering et non-oracle, reproduction indépendante des vecteurs, audit des frontières et graphes Cargo. Le checkpoint opérateur est vert. `pre.010` finalise README/USAGE, la spec, les graphes, la matrice de clôture et le prompt `0.2.6` sans changement de code ni de version Cargo technique. `rel.001` est la prochaine étape et reste strictement publicationnelle.
## `0.2.6` — Wallet Desk
Mission : valider Config composite + `.kspwallet` + transport HTTP dans une application Tauri mince.
Le solde d'un wallet constitue un premier cas de validation réseau obligatoire.
Le solde d'un wallet constitue un premier cas de validation réseau obligatoire. L'application garde les handles VIEW/OWNER côté Rust, ne persiste aucun password dans Config/frontend et délègue toute crypto/signature/administration à `ksp-wallet-lib`.
Le prompt [`../../prompts/011-V0_2_6_START_PROMPT.md`](../../prompts/011-V0_2_6_START_PROMPT.md), préparé par `0.2.5-pre.010`, impose un `pre.001` d'audit/sizing couvrant Config `std.wallet`/composite, inventory/path safety, lifecycle VIEW/OWNER, balance `getBalance`, bridge Tauri/TS-RS, sécurité password/export, logging et validation finale Tauri.
## `0.2.7` — WebSocket Solana standard

View File

@@ -1,5 +1,5 @@
<!-- file: docs/plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md -->
<!-- version: 12 -->
<!-- version: 13 -->
# Plan `0.2.5` — Wallet foundation
@@ -1085,6 +1085,22 @@ Toutes les mutations persistent un état staged puis ne mettent à jour le handl
La rotation simple VIEW rewrappe le même `K_metadata` et n'est pas une révocation forte. `disable_view`/`recreate_view` génèrent au contraire un nouveau `K_metadata`, rechiffrent les metadata et réécrivent `owner_control`; elles constituent la révocation forte des futures metadata de l'état courant. Dans tous les cas, `format_version` et la keypair Solana restent inchangés.
### 19.10 État acquis après `pre.010`
La tranche de clôture est documentaire et ne modifie ni Rust, ni Cargo, ni wire :
```text
README Wallet final
USAGE Wallet final
KSPWALLET_V1.md synchronisée en candidate V1
matrice validation 008 enrichie des preuves opérateur pre.009
graphe de dépendances Wallet finalisé
prompt 0.2.6 Wallet Desk préparé
liens Markdown locaux audités
```
`workspace.package.version` reste `0.2.5-pre.9` pendant `pre.010` conformément à la règle KSP de version technique ; `rel.001` effectuera le passage à `0.2.5`.
## 20. Sizing
| Domaine | Taille | Risque principal |
@@ -1117,16 +1133,16 @@ pre.005 owner-control + metadata/secret compartments + create/open VIEW/OWNER +
pre.006 persistence async/atomic/no-clobber + interrupted-write + fault/concurrency tests
pre.007 signature Solana + alias/notes + rotations passwords + disable/recreate VIEW avec rekey metadata
pre.008 import/export adapters + Solana CLI JSON + generic keypair Base58 + inspect
pre.009 audit security/interoperability/compliance + adversarial vectors/tests + cargo trees
pre.010 spec finale + README/USAGE + graphes/docs + candidate de clôture + prompt 0.2.6
rel.001 publication strictement publicationnelle
pre.009 audit security/interoperability/compliance + adversarial vectors/tests + cargo trees acquis
pre.010 spec finale + README/USAGE + graphes/docs + candidate de clôture + prompt 0.2.6 acquis
rel.001 publication strictement publicationnelle prochaine
```
Une `fix` ou tranche supplémentaire est préférable à la suppression d'une garantie sécurité si un des gates révèle une incompatibilité.
## 22. Dépendances par tranche
État réellement acquis au terme de `pre.009` :
État réellement acquis au terme de `pre.010` (aucune dépendance ajoutée par la tranche documentaire finale) :
```text
pre.002 zeroize ^1.9
@@ -1141,6 +1157,7 @@ pre.006 tempfile ^3.27
pre.007 aucune nouvelle dépendance tierce
pre.008 aucune nouvelle dépendance tierce
pre.009 aucune nouvelle dépendance tierce
pre.010 aucune nouvelle dépendance tierce (documentation uniquement)
```
Toutes les dépendances tierces communes restent centralisées sous `[workspace.dependencies]`; le membre Wallet active uniquement les features nécessaires. `ed25519-dalek ^2.2` est volontairement aligné avec la contrainte `^2.1.1` de `solana-keypair 3.1.2` afin de permettre une seule génération Dalek et d'activer `zeroize` sur la `SigningKey` partagée par résolution Cargo.
@@ -1179,7 +1196,7 @@ Solana RPC clients
Config/Store/Tauri
```
Le fait que `bs58` ne soit pas requis sera révalidé lorsque les adapters sont codés : `solana-keypair` fournit déjà la conversion Base58 du keypair complet.
L'absence de dépendance `bs58` directe est désormais acquise : `pre.008` utilise le codec Base58 de keypair complète déjà fourni par `solana-keypair`, et `pre.009` confirme le graphe Cargo sans ajout correspondant.
## 23. Sources externes réauditées
@@ -1232,6 +1249,8 @@ cargo tree et diagnostics secrets sont audités
README/USAGE/spec/vecteurs sont cohérents
```
À `pre.010`, ces critères sont satisfaits par la candidate documentée et par le checkpoint opérateur `pre.009` vert. La publication stable reste conditionnée à la validation du delta documentaire puis au workflow `rel.001`.
## 25. Hors périmètre confirmé
```text
@@ -1258,4 +1277,4 @@ Une future `format_version >= 2` pourra réétudier des facteurs/ancrages extern
## 26. Suite immédiate
`0.2.5-pre.003` fige le codec JSON strict, les limites structurelles, `slot_id` 16 octets, le descripteur VIEW, les DTOs denveloppe/key slots, les TLV transcript/AAD et la première spécification `docs/formats/KSPWALLET_V1.md`. `pre.004` ajoute Argon2id/XChaCha20-Poly1305/CSPRNG OS et le wrapping de content keys. Le benchmark opérateur permet à `pre.005` de retenir le profil initial `64 MiB / 3 / 1`, de figer les payloads `owner_control`/metadata/secret, d'introduire l'autorité Ed25519 OWNER distincte de la keypair Solana et de publier un vecteur complet. `pre.006` ajoute la persistence no-clobber et les ouvertures fichier. `pre.007` ajoute signature Solana, administration metadata, rotations OWNER/VIEW, révocation forte VIEW et remplacement administratif contrôlé. `pre.008` ajoute les adapters import/export Solana CLI JSON et keypair Base58 complet, l'inspection sûre, l'import vers un nouveau `.kspwallet` no-clobber et l'export OWNER explicite sans `bs58` direct. `pre.009` ajoute maintenant les canaris adversariaux, formalise les règles Wallet durables, reproduit les vecteurs hors Rust/KSP et audite le graphe Cargo/les duplications transitoires. **La suite immédiate est `pre.010` : documentation finale, README/USAGE Wallet, candidate de clôture et prompt `0.2.6`.**
`0.2.5-pre.003` fige le codec JSON strict, les limites structurelles, `slot_id` 16 octets, le descripteur VIEW, les DTOs denveloppe/key slots, les TLV transcript/AAD et la première spécification `docs/formats/KSPWALLET_V1.md`. `pre.004` ajoute Argon2id/XChaCha20-Poly1305/CSPRNG OS et le wrapping de content keys. Le benchmark opérateur permet à `pre.005` de retenir le profil initial `64 MiB / 3 / 1`, de figer les payloads `owner_control`/metadata/secret, d'introduire l'autorité Ed25519 OWNER distincte de la keypair Solana et de publier un vecteur complet. `pre.006` ajoute la persistence no-clobber et les ouvertures fichier. `pre.007` ajoute signature Solana, administration metadata, rotations OWNER/VIEW, révocation forte VIEW et remplacement administratif contrôlé. `pre.008` ajoute les adapters import/export Solana CLI JSON et keypair Base58 complet, l'inspection sûre, l'import vers un nouveau `.kspwallet` no-clobber et l'export OWNER explicite sans `bs58` direct. `pre.009` ajoute les canaris adversariaux, formalise les règles Wallet durables, reproduit les vecteurs hors Rust/KSP et audite le graphe Cargo/les duplications transitoires. `pre.010` finalise README/USAGE, spec, graphes, matrice de validation et prompt `0.2.6` sans changement de code ni de Cargo version. **La suite immédiate est `0.2.5-rel.001`, strictement publicationnelle.**

View File

@@ -1,5 +1,5 @@
<!-- file: docs/validation/000-README.md -->
<!-- version: 12 -->
<!-- version: 13 -->
# Validations KSP
@@ -17,4 +17,4 @@ Documents :
- [`006-V0_2_3_HTTP_TRANSACTIONS.md`](006-V0_2_3_HTTP_TRANSACTIONS.md) — matrice finale validée de `0.2.3`, 11 wrappers Transactions, sécurité write/simulation, réaudit 52+14, `KSP-TRANSPORT-007` 37/37, graphes Cargo et deux smokes Devnet passés avant publication stable.
- [`007-V0_2_4_HTTP_FINAL_COMPLIANCE.md`](007-V0_2_4_HTTP_FINAL_COMPLIANCE.md) — matrice finale validée de `0.2.4`, inventaire exact 52 current + 14 Deprecated, preuve typed 52/52, audit SIMD final, `KSP-TRANSPORT-007`, workspace complet et deux smokes Devnet passés avant publication stable.
- [`008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md`](008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md) — matrice security/interoperability/compliance de `0.2.5`, threat model V1, adversarial canaries, reproduction externe des vecteurs, audit de frontières et graphes Cargo Wallet.
- [`008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md`](008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md) — matrice finale security/interoperability/compliance de `0.2.5`, threat model V1, adversarial canaries, reproduction externe des vecteurs, audit de frontières, preuves opérateur `pre.009`, graphes Cargo et gate documentaire `pre.010`.

View File

@@ -1,11 +1,11 @@
<!-- file: docs/validation/008-V0_2_5_WALLET_SECURITY_COMPLIANCE.md -->
<!-- version: 1 -->
<!-- version: 3 -->
# Validation `0.2.5` — Wallet security / interoperability / compliance
## 1. Objet
Cette matrice ferme le gate technique de `0.2.5-pre.009` avant la documentation finale `pre.010`. Elle ne remplace ni la spécification [`../formats/KSPWALLET_V1.md`](../formats/KSPWALLET_V1.md), ni le threat model du plan [`../plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md`](../plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md), ni les deltas.
Cette matrice constitue la validation durable de clôture de `0.2.5`. `pre.009` ferme le gate technique security/interoperability/compliance et `pre.010` y ajoute les preuves opérateur et le gate documentaire final. Elle ne remplace ni la spécification [`../formats/KSPWALLET_V1.md`](../formats/KSPWALLET_V1.md), ni le threat model du plan [`../plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md`](../plans/012-V0_2_5_WALLET_FOUNDATION_PLAN.md), ni les deltas.
Le verdict recherché porte sur quatre axes :
@@ -111,7 +111,7 @@ Références cryptographiques normatives/primaires réauditées :
- documentation `solana-keypair 3.1.2` — keypair Ed25519 64 octets, validation secret/public et codecs Base58/JSON ;
- documentation `tempfile 3.27` — publication/replacement et limites d'atomicité selon OS/filesystem.
## 6. Audit Cargo observé après `pre.008`
## 6. Audit Cargo final observé après `pre.009`
Commande opérateur :
@@ -198,7 +198,7 @@ Le verdict security est positif **dans le threat model documenté**, avec les li
6. `zeroize` s'applique aux buffers possédés explicitement mais ne prouve pas l'effacement physique de toutes les copies potentielles ;
7. aucune protection hardware, second facteur, keychain, remote signer ou anti-rollback externe n'est incluse en V1.
Aucune de ces limites ne doit être masquée dans `pre.010`.
`pre.010` les conserve explicitement dans README/USAGE/spec et ne les transforme pas en garanties.
## 9. Gate opérateur `pre.009`
@@ -217,8 +217,59 @@ cargo tree -i solana-keypair@3.1.2
cargo tree -i solana-address@2.7.0
```
Le gate est vert seulement si les canaris adversariaux passent sans warning et si le tree ne révèle aucune nouvelle dépendance directe ou génération Dalek/Solana-address inattendue.
Ce gate est considéré vert uniquement si les canaris adversariaux passent sans warning et si le tree ne révèle aucune nouvelle dépendance directe ou génération Dalek/Solana-address inattendue ; le résultat effectivement observé est enregistré en section 10.
## 10. Verdict avant `pre.010`
## 10. Résultat opérateur `pre.009`
Le verdict de conception et d'interopérabilité est **positif sous réserve du checkpoint Cargo opérateur `pre.009`**. Aucun changement de wire/crypto n'est requis par l'audit. `pre.010` doit donc rester documentaire : README/USAGE Wallet, synchronisation finale de la spec/graphes, candidate de clôture et prompt `0.2.6`.
Checkpoint communiqué le 2026-08-19 après application de `0.2.5-pre.009` :
```text
cargo fmt --all OK
cargo check --workspace OK, aucun warning
cargo clippy --workspace --all-targets OK, aucun warning
cargo test -p ksp-wallet-lib OK
unit 58 passed / 1 ignored
dependency_boundary 3 passed
public_api 9 passed
doctests 2 passed
cargo test --workspace OK
```
Le tree opérateur confirme :
```text
ed25519-dalek 2.2.0
<- ksp-wallet-lib
<- solana-keypair 3.1.2 <- ksp-wallet-lib
solana-keypair 3.1.2
<- ksp-wallet-lib uniquement comme parent KSP direct
solana-address 2.7.0
<- solana-keypair 3.1.2
<- solana-pubkey 4.3.0 via ksp-core-lib
```
Les doublons transitifs déjà inventoriés restent inchangés et aucun nouveau bypass de frontière n'est observé.
## 11. Gate documentaire `pre.010`
La candidate finale doit vérifier :
```text
crates/ksp-wallet-lib/README.md existe et décrit les responsabilités/frontières
crates/ksp-wallet-lib/USAGE.md couvre create/open/sign/admin/rotation/import/export
KSPWALLET_V1.md ne laisse aucune opération V1 planifiée comme restant à implémenter
le graphe Wallet documente Pubkey via Core et keypair encapsulée dans Wallet
le plan 0.2.5 pointe désormais vers rel.001
le prompt 0.2.6 Wallet Desk existe et commence par audit/sizing
les liens Markdown locaux modifiés sont valides
aucun fichier Rust ni manifest Cargo n'est modifié par pre.010
workspace.package.version reste 0.2.5-pre.9 car pre.010 est doc-only
```
## 12. Verdict final candidate `0.2.5`
Le verdict security/interoperability/compliance est **positif**. Le checkpoint opérateur `pre.009` est vert et n'impose aucune remédiation de code, de dépendance, de wire ou de cryptographie. `pre.010` reste donc strictement documentaire et nintroduit aucun changement technique.
Après validation du delta documentaire, la suite est `0.2.5-rel.001`, strictement publicationnelle : version Cargo stable `0.2.5`, statut stable/CHANGELOG/delta de publication, validations finales puis tag Git `v0.2.5`. Aucune nouvelle fonctionnalité Wallet n'est attendue dans `rel.001`.