Sasedev/khadhroony-solana-project

Fork 0

Files

SinuS Von SifriduS 804b92b957 v0.2.4-pre.009-fix.001

2026-08-18 23:26:17 +02:00

31 KiB

Raw Blame History

Prompt de démarrage `0.2.5` — Wallet foundation

1. Contexte de reprise

La base attendue est la release stable :

v0.2.4

0.2.1 à 0.2.4 ont stabilisé la foundation HTTP Solana puis complété toute la surface HTTP courante auditée :

52/52 méthodes HTTP courantes avec wrapper typed
14/14 méthodes historiques Deprecated / runtime Removed conservées
KSP-TRANSPORT-007 appliqué à la surface complète

La prochaine release est :

0.2.5 — Wallet foundation

Sa mission n'est pas d'ajouter une UI ni de commencer l'exécution métier. Elle introduit le cœur Wallet autonome dont les applications et l'exécution future pourront dépendre.

La première tranche est :

0.2.5-pre.001

et commence obligatoirement par audit actuel + reprise de l'héritage utile + brainstorming + threat model + sizing avant toute implémentation cryptographique ou format lourd.

2. Mission de `0.2.5`

Créer :

crates/ksp-wallet-lib

et stabiliser le format natif :

.kspwallet

Le Wallet doit fournir au minimum les capacités conceptuelles suivantes :

création
ouverture / déverrouillage
identité publique après autorisation
protection du secret
signature
capacité VIEW indépendante
capacité OWNER indépendante
changement/rotation des mots de passe sans changement de keypair
alias interne indépendant du filename
notes internes protégées
persistence atomique / no-clobber
projection sûre selon capacité
import/export extensible
interopérabilité externe documentée du format natif

La release doit aboutir à une bibliothèque utilisable sans Config, sans Transport, sans Tauri et sans execution policy.

Le format .kspwallet ne doit pas dépendre de l'existence future de KSP pour rester récupérable. Une implémentation externe conforme doit pouvoir le lire/déchiffrer avec les bons secrets d'accès à partir d'une spécification publique et de vecteurs de test.

3. Frontières architecturales déjà décidées

La direction attendue reste :

ksp-wallet-lib
    -> ksp-core-lib
    -> ksp-logging-lib
    -> primitives crypto/key/signature low-level explicitement retenues

Interdictions :

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-> Store
ksp-wallet-lib -X-> Tauri

Le Wallet stocke, ouvre et signe. Il ne décide pas si une transaction ou une dépense est autorisée.

Les règles de dépense, programme, réseau, simulation, plafonds ou approbation appartiennent à la future frontière :

ksp-execution-policy-api

et non à ksp-wallet-lib.

4. Décisions Wallet déjà acquises

Les décisions suivantes ne doivent pas être rouvertes sans raison nouvelle et documentée :

le format natif KSP se nomme .kspwallet ;
KSP ne crée pas de ksp-wallet-api séparée dans l'architecture actuelle ;
WalletPolicy est explicitement exclu du Wallet ;
le wallet JSON temporaire historique bot2/bot3 n'est pas migré ;
l'ancien nom .kswallet n'est pas le nom final KSP ;
les secrets wallet ne doivent jamais être déplacés dans Config par commodité ;
Wallet n'a pas besoin de Transport pour son cœur ;
l'import/export doit rester extensible, mais seules les conversions réellement nécessaires doivent être implémentées ;
les futurs scénarios doivent pouvoir utiliser de vrais .kspwallet, y compris des wallets dédiés Devnet/tests ;
Wallet Desk arrive séparément en 0.2.6 ;
le format .kspwallet doit être documenté et implémentable en dehors de KSP ; la sécurité ne doit jamais dépendre de la confidentialité du format ;
aucun secret global KSP, pepper propriétaire ou donnée cachée dans le logiciel ne doit être nécessaire pour récupérer un .kspwallet autonome ;
la Pubkey, l'alias et les notes ne sont pas lisibles wallet verrouillé par défaut ;
l'alias est une identité humaine interne au wallet et reste indépendant du nom du fichier ;
les notes sont des metadata internes protégées et peuvent être ajoutées/modifiées/supprimées par la capacité OWNER ;
le format_version décrit la version du format, pas un compteur d'éditions, de changements de mot de passe ou de metadata ;
les paramètres cryptographiques nécessaires au déchiffrement doivent être sérialisés dans le fichier afin que les anciens wallets restent lisibles après durcissement futur des paramètres par défaut ;
le modèle cible possède deux capacités indépendantes :
- VIEW : lecture Pubkey/alias/notes ;
- OWNER : toutes les capacités VIEW + signature + administration du wallet ;
OWNER ne doit jamais dépendre de VIEW : la perte du password VIEW ne doit pas empêcher l'ouverture, la signature ou l'administration avec OWNER ;
un compromis du password VIEW ne doit pas permettre d'obtenir le secret Solana ni une clé permettant de dériver/déverrouiller la capacité OWNER ;
la rotation d'un password VIEW ou OWNER ne doit pas modifier la keypair Solana ;
OWNER doit pouvoir remplacer/supprimer/recréer la capacité VIEW sans connaître l'ancien password VIEW.

Références KSP à relire avant le plan :

docs/rules/RULES_KSP.md
docs/rules/RULES_DEPENDENCIES.md
docs/architecture/002-LAYERS_AND_DEPENDENCIES.md
docs/architecture/003-COMPONENT_CONTRACTS.md
docs/architecture/004-COMPONENT_INVENTORY.md
docs/architecture/005-DEPENDENCY_GRAPH.md
docs/architecture/007-EXECUTION_AND_POLICY.md
docs/plans/002-FUNCTIONAL_RELEASE_SEQUENCE.md
docs/plans/007-V0_2_0_SERIES_PLANNING.md
docs/validation/002-V0_2_0_SERIES_PLANNING.md
docs/IDEAS.md

5. `pre.001` — audit officiel actuel + brainstorming + threat model + sizing

pre.001 ne doit pas démarrer directement par le chiffrement du fichier.

Il doit d'abord produire un plan Wallet dédié et répondre explicitement aux questions suivantes.

5.1 Héritage bot3/bot2

Réaduiter les implémentations historiques réellement disponibles de Wallet afin de classer chaque idée en :

réutiliser conceptuellement
refondre
abandonner
reporter

Examiner notamment, lorsqu'ils existent dans les sources historiques :

création de keypair ;
lecture/écriture du format wallet ;
modèle de mot de passe ;
secret/public separation ;
changement de mot de passe ;
signature ;
import/export ;
aliases/metadata ;
atomicité/no-clobber ;
redaction ;
temporary wallet JSON ;
ancien .kswallet ;
WalletPolicy.

Ne pas copier automatiquement une dépendance, un format ou une primitive cryptographique uniquement parce qu'elle existait dans bot3.

5.2 Threat model du `.kspwallet`

Le plan doit documenter explicitement au minimum les scénarios suivants :

attaquant obtient une copie du fichier .kspwallet
attaquant peut lancer des essais de password hors ligne sans limite serveur
attaquant connaît intégralement la spécification du format
attaquant connaît les algorithmes et paramètres KDF/AEAD stockés dans le fichier
attaquant connaît seulement le password VIEW
attaquant connaît seulement le password OWNER
attaquant peut modifier partiellement le fichier
attaquant peut remplacer totalement le fichier sur le filesystem

Conclusions à préserver :

le format ouvert/documenté n'est pas une faiblesse de sécurité ;
un wallet protégé uniquement par password reste attaquable offline par dictionnaire/bruteforce ;
le KDF rend chaque tentative coûteuse mais ne transforme pas un mauvais password en secret à forte entropie ;
le salt doit empêcher la réutilisation efficace de précalculs entre wallets, pas être traité comme un secret ;
aucun rate-limit applicatif KSP ne protège un fichier déjà volé ;
la résistance au remplacement total d'un fichier ne peut pas être promise uniquement par une information de confiance stockée dans ce même fichier ;
les garanties de VIEW read-only doivent distinguer clairement la sécurité de l'API KSP de la résistance cryptographique à un détenteur VIEW malveillant.

Le plan doit déterminer quelles garanties sont assurées :

par la cryptographie du fichier
par les types/capabilities de ksp-wallet-lib
par les permissions/persistence filesystem
par une éventuelle ancre de confiance externe future

5.3 Primitives Solana actuelles

Réaduiter les crates low-level Solana réellement nécessaires pour :

Pubkey
keypair / secret material
Signer
Signature

Objectifs :

garder les dépendances au niveau le plus bas possible ;
ne pas tirer un client RPC Solana ;
ne pas recréer localement une primitive cryptographique standard bien maintenue ;
conserver toutes les dépendances tierces communes dans [workspace.dependencies].

L'audit doit vérifier les versions réellement actuelles au moment de la session, pas recopier les versions historiques bot3.

5.4 Protection cryptographique du fichier

Comparer les primitives cryptographiques maintenues et adaptées au besoin réel du .kspwallet.

Le plan doit décider explicitement, avec justification :

KDF password
AEAD / chiffrement authentifié
CSPRNG
key wrapping / envelope encryption
gestion salt / nonce
paramètres KDF sérialisés
format_version
payload_version si distinct et justifié
stratégie de migration
zeroization / secret memory handling
authentification OWNER des metadata si VIEW doit être cryptographiquement read-only

Ne pas inventer de cryptographie KSP.

La shortlist à réauditer inclut au minimum :

KDF:
    Argon2id        favori actuel à confirmer
    scrypt          alternative memory-hard
    PBKDF2          compatibilité/legacy, pas favori sans raison

AEAD:
    XChaCha20-Poly1305
    AES-256-GCM-SIV
    autres alternatives seulement si elles apportent un avantage documenté

Secret memory:
    zeroize
    secrecy ou types KSP simples basés sur zeroize

Cette shortlist n'est pas un verrouillage. pre.001 doit vérifier l'état réel des crates, audits, maintenance, risques de nonce, portabilité, interopérabilité et dépendances avant décision.

Le KDF ne doit pas recevoir des paramètres copiés arbitrairement d'un RFC ou d'un ancien projet. Les paramètres de création par défaut doivent être benchmarkés sur les machines cibles et conçus pour pouvoir être durcis plus tard sans rendre les wallets existants illisibles.

5.5 Architecture de clés et capacités `VIEW` / `OWNER`

Le design ne doit pas chiffrer naïvement « tout le wallet avec deux passwords successifs ».

Le plan doit étudier une architecture de content keys + key slots, conceptuellement de la forme :

password VIEW
    -> KDF VIEW
    -> VIEW key slot
    -> accès metadata seulement

password OWNER
    -> KDF OWNER
    -> OWNER key slot
    -> root/owner capability
        -> accès metadata
        -> accès secret Solana
        -> signature
        -> administration / rotations

Invariants obligatoires :

VIEW et OWNER ont des KDF/salts indépendants
OWNER ne dépend jamais de VIEW
VIEW compromis != secret Solana compromis
VIEW compromis != OWNER compromis
OWNER peut recréer/supprimer VIEW sans ancien password VIEW
rotation VIEW != rechiffrement ou changement de keypair obligatoire
rotation OWNER != changement de keypair

Le plan doit décider si les key slots sont sérialisés sous une structure générique telle que :

key_slots:
    - role: view
    - role: owner

afin de conserver une extensibilité future sans implémenter dès V1 des rôles tels que recovery/hardware/automation.

`VIEW` réellement read-only

Dans l'API publique KSP, VIEW est obligatoirement read-only :

VIEW:
    lire Pubkey
    lire alias
    lire notes

VIEW -X-> signer
VIEW -X-> modifier alias/notes
VIEW -X-> changer passwords
VIEW -X-> exporter le secret

Cependant une clé symétrique permettant de déchiffrer un compartiment peut généralement aussi servir à produire un nouveau ciphertext valide pour ce même compartiment.

pre.001 doit donc trancher explicitement le niveau recherché :

A. read-only garanti seulement par les capabilities/types KSP
B. read-only également renforcé cryptographiquement contre un détenteur VIEW malveillant

La préférence de conception est B si elle peut être réalisée proprement et interopérablement sans complexité disproportionnée.

Si B est retenu, étudier une authentification des metadata contrôlée par OWNER, idéalement avec une autorité de contrôle distincte de la keypair Solana sauf justification contraire. Ne pas réutiliser automatiquement la clé de signature blockchain comme clé d'administration du format.

La documentation doit rester honnête : même une metadata correctement authentifiée ne peut pas, à elle seule, empêcher quelqu'un ayant accès en écriture au filesystem de remplacer entièrement le fichier par un autre fichier valide.

5.6 Modèle de fichier `.kspwallet`

Le plan doit définir les invariants du format avant l'API de persistence.

Le format doit séparer conceptuellement :

enveloppe publique minimale
key slots / paramètres nécessaires au déverrouillage
compartiment metadata protégé
compartiment secret protégé

L'enveloppe publique verrouillée ne doit exposer par défaut que ce qui est strictement nécessaire à l'interprétation/déverrouillage, par exemple :

magic
format_version
suite/identifiants crypto
paramètres KDF
salts
nonces ou équivalents
wrapped keys / key slots
ciphertexts

Ne doivent pas être lisibles sans VIEW ou OWNER :

Pubkey
alias
notes
secret Solana

Le compartiment metadata déverrouillé par VIEW ou OWNER doit pouvoir contenir au minimum :

Pubkey
alias optionnel
notes optionnelles

L'alias :

est indépendant du filename
peut être modifié par OWNER
peut être absent

Les notes :

peuvent être ajoutées/modifiées/supprimées par OWNER
sont lisibles par VIEW et OWNER
ne doivent jamais être exposées wallet verrouillé
doivent avoir des limites de taille explicites

Le compartiment secret n'est accessible qu'à OWNER et contient le matériau nécessaire aux opérations de signature.

Questions à trancher :

JSON, binaire ou enveloppe hybride ;
magic/version ;
représentation de la Pubkey ;
encodages exacts des salts/nonces/ciphertexts ;
schéma des key slots ;
champs obligatoires/optionnels ;
limites de taille globales et par champ ;
politique unknown-version ;
politique unknown-field ;
migrations futures ;
checksum séparé utile ou redondant avec AEAD/authentification ;
compatibilité endianness/encodage si format binaire ;
canonicalisation nécessaire si des signatures/authentifications couvrent des structures sérialisées.

5.7 Versionnement et migration

Le plan doit distinguer clairement :

format_version

de tout historique de modification.

format_version signifie :

comment parser/interpréter ce fichier

et ne doit pas être incrémenté pour :

changement de password
changement d'alias
ajout/modification/suppression de note
réécriture atomique sans changement de schéma/crypto

Étudier séparément un éventuel :

payload_version

uniquement si l'évolution du contenu protégé justifie une frontière distincte de l'enveloppe.

La stratégie doit permettre par exemple :

wallet ancien:
    paramètres KDF plus faibles mais sérialisés

nouveau défaut KSP:
    paramètres KDF plus forts

=> les deux restent lisibles

Toute migration automatique future doit être explicite, testable et atomique.

5.8 Interopérabilité externe obligatoire

Le .kspwallet ne doit pas être un format « lisible seulement par ksp-wallet-lib ».

La release doit prévoir une spécification indépendante du code, par exemple :

docs/formats/KSPWALLET_V1.md

avec au minimum :

grammaire/structure exacte ;
suites crypto et paramètres ;
encodages ;
dérivation/wrapping ;
données authentifiées ;
ordre/canonicalisation lorsque pertinent ;
règles de parsing/rejet ;
limites ;
comportement unknown-version ;
procédure VIEW ;
procédure OWNER ;
procédure de rotation ;
vecteurs de test.

Des test vectors publics déterministes doivent permettre à une implémentation externe en Rust, Python, Go, C ou autre de vérifier qu'elle dérive/déchiffre exactement les mêmes données.

Le test vector peut naturellement contenir un password connu et un secret explicitement test-only ; il ne doit jamais être présenté comme wallet sûr de production.

5.9 Secret en mémoire

Définir explicitement l'ownership du secret déverrouillé.

Au minimum :

pas de Debug/Display révélant le secret ;
pas de valeur secrète dans les erreurs/logs/contextes KSP ;
éviter Copy et les clones implicites de secret ;
zeroization des buffers possédés lorsque raisonnablement possible ;
durée de vie du secret déverrouillé explicitement contrôlée ;
distinction nette metadata / encrypted payload / unlocked secret ;
aucune conservation du password en clair au-delà du besoin cryptographique ;
VIEW ne doit jamais matérialiser le secret Solana ;
le déverrouillage OWNER doit éviter l'exposition du secret brut aux consommateurs qui n'ont besoin que de sign().

Le plan doit être honnête sur les limites réelles de zeroization dans Rust et des allocations/transcodages choisis ; ne pas promettre une garantie que la stack ne peut pas fournir.

5.10 Persistence et opérations d'administration

Définir la stratégie :

create
open VIEW
open OWNER
atomic replace
no-clobber create
rotate VIEW password
remove VIEW capability
create/recreate VIEW capability
rotate OWNER password
modify alias
add/update/delete notes
permissions filesystem
recovery after interrupted write

La rotation de password doit :

conserver la même identité/keypair ;
produire un nouveau matériau de protection approprié ;
ne pas dégrader l'atomicité ;
ne jamais laisser un fichier partiellement remplacé comme nouveau wallet valide ;
permettre à OWNER de gérer VIEW sans connaître l'ancien VIEW password.

Le plan doit distinguer comportement portable et durcissement spécifique Unix si nécessaire.

5.11 Import/export extensible

Établir une architecture ouverte qui permette d'ajouter des formats sans enum central fermé imposant de modifier le cœur à chaque intégration.

Auditer les formats réellement utiles maintenant parmi les pistes historiques, par exemple :

Solana CLI keypair JSON
Backpack
Phantom
Solflare
Trust Wallet
autres formats réellement disponibles dans les sources/audits

Cette liste est une liste d'audit, pas un engagement d'implémentation complet.

pre.001 sélectionne le minimum de formats nécessaire pour prouver l'extensibilité et le round-trip utile de la release.

Ne pas ajouter des dépendances « au cas où ».

5.12 Sizing

Évaluer séparément :

crate/API foundation
threat model
format wire
interop/test vectors
KDF/AEAD/key wrapping
VIEW/OWNER key slots
authentification cryptographique metadata si retenue
persistence
signing
password/key-slot rotation
metadata alias/notes
import/export
security tests
docs/USAGE + format specification

Si le scope ne paraît plus clôturable proprement dans la session, découper avant l'implémentation lourde plutôt que réduire silencieusement les garanties de sécurité.

6. API publique à concevoir

Les noms exacts sont décidés pendant le plan, mais les responsabilités doivent rester distinctes.

Il doit exister des contrats clairs pour :

wallet locked/encrypted representation
wallet VIEW capability
wallet OWNER capability
wallet metadata/info après autorisation
create/open/save
rotate/remove/create key slots
import/export/inspect

La séparation conceptuelle minimale attendue est :

WalletView
    -> pubkey()
    -> alias()
    -> notes()

WalletOwner
    -> tout WalletView
    -> sign(...)
    -> update_alias(...)
    -> add/update/delete_note(...)
    -> rotate_view_password(...)
    -> disable/recreate_view(...)
    -> rotate_owner_password(...)

Les noms ne sont pas imposés, les capacités oui.

Ne pas exposer directement un champ secret: Vec<u8> comme API publique de commodité.

Une API explicitement dangereuse d'export du secret ne doit exister que si un format d'export retenu l'exige réellement et avec une sémantique qui évite l'exposition accidentelle.

La capacité de signature doit permettre aux couches supérieures d'obtenir une signature sans devoir extraire le secret brut.

7. Erreurs

Utiliser le type d'erreur commun KSP.

Prévoir des catégories suffisamment précises pour distinguer au minimum :

format invalide
version non supportée
paramètres crypto invalides
authentification/déchiffrement échoué
VIEW password invalide/non déverrouillable
OWNER password invalide/non déverrouillable
capability insuffisante
I/O
no-clobber / destination existante
persistence atomique
import/export non supporté
key material invalide
signature

Les messages et contextes ne doivent pas contenir :

password
secret bytes
seed phrase
private key
payload chiffré complet
KDF input

Éviter également de créer un oracle inutile en distinguant trop finement les causes d'échec d'authentification lorsque cela affaiblirait la sécurité.

8. Logging

ksp-wallet-lib utilise exclusivement la façade ksp-logging-lib.

Les événements utiles peuvent inclure :

opération create/open-view/open-owner/import/export/rotate/sign
format/version non secrète
type de capability sans password
succès/échec catégorisé
durée
destination/path seulement selon politique sûre retenue

Ne jamais logger :

password VIEW
password OWNER
secret
seed
private key
signature payload arbitraire
contenu complet du wallet
ciphertext complet
nonce/salt si le log n'en a aucun besoin opérationnel
alias/notes par défaut

Même trace ne constitue pas une exception.

9. Tests de sécurité et de contrat

Les tests déterministes doivent couvrir au minimum les domaines suivants.

Format

round-trip du format natif ;
magic/format_version corrects ;
unknown version rejetée ;
fichier tronqué/reformaté rejeté ;
champs/tailles invalides rejetés ;
corruption/tampering détectée ;
absence du secret, de la Pubkey, de l'alias et des notes en clair dans le fichier verrouillé ;
paramètres KDF/crypto nécessaires au déverrouillage présents et cohérents ;
vecteurs de test externes reproductibles.

VIEW / OWNER

VIEW correct lit Pubkey/alias/notes ;
VIEW ne peut pas signer via l'API ;
VIEW ne peut pas modifier alias/notes via l'API ;
VIEW ne peut pas administrer les key slots ;
VIEW ne peut pas obtenir le secret Solana ;
OWNER lit tout ce que VIEW lit ;
OWNER signe ;
OWNER modifie alias/notes ;
OWNER peut changer VIEW sans ancien VIEW password ;
OWNER peut supprimer puis recréer VIEW ;
OWNER fonctionne même si VIEW est perdu/inconnu ;
compromise/knowledge de VIEW ne permet pas d'ouvrir OWNER ;
VIEW et OWNER utilisent salts/KDF material indépendants.

Si le read-only cryptographique est retenu :

un détenteur VIEW ne peut pas produire une modification de metadata acceptée comme authentique par la vérification prévue ;
les limites face au remplacement total du fichier sont documentées et testées seulement dans la mesure réellement possible.

Password / crypto

bon VIEW password ouvre VIEW seulement ;
bon OWNER password ouvre OWNER ;
mauvais password échoue sans fuite ;
rotation VIEW conserve Pubkey/keypair ;
rotation OWNER conserve Pubkey/keypair ;
anciens passwords ne déverrouillent plus les key slots remplacés ;
nouveaux passwords fonctionnent ;
salt/nonce/paramètres ne sont pas accidentellement réutilisés lorsque le design impose leur renouvellement ;
les paramètres KDF enregistrés permettent de rouvrir un wallet après changement des defaults KSP.

Metadata

alias indépendant du filename ;
alias absent/présent/modifié ;
notes absentes/présentes ;
ajout/modification/suppression de notes ;
limites de taille ;
metadata non visible sans VIEW/OWNER ;
metadata conservée lors d'une rotation OWNER/VIEW sauf modification explicite.

Secret / diagnostics

Debug/snapshots/projections VIEW/OWNER ne contiennent pas le secret ;
erreurs n'échoent pas passwords/secret ;
logs de test ne contiennent pas de secret ni metadata non autorisée ;
types secrets n'acquièrent pas Copy par accident ;
zeroization testable lorsqu'elle est réellement observable sans faux sentiment de sécurité.

Persistence

create ;
destination existante/no-clobber ;
write atomique ;
remplacement lors des rotations/admin changes ;
échec intermédiaire ne détruisant pas le wallet précédent, dans la mesure testable par la couche ;
permissions/durcissement filesystem retenus.

Signature

Pubkey dérivée correcte ;
signature produite et vérifiable ;
rotations VIEW/OWNER ne changent pas la signature déterministe d'un même message si la primitive de signature est déterministe ;
VIEW ne peut pas signer ;
le consumer OWNER peut signer sans extraction publique du secret brut.

Import/export

format(s) retenu(s) ;
validation stricte ;
round-trip lorsque le format le permet ;
inspect sans import si cette capability est retenue ;
architecture extensible démontrée sans dépendance au format natif dans les adapters externes.

Public API / architecture

canary publique depuis crate root ;
aucune dépendance Wallet -> Config/Transport/ExecutionPolicy ;
aucune dépendance crypto dupliquée injustifiée ;
aucun accès environnement direct ;
aucun unsafe ajouté.

10. Tests et fixtures contenant des secrets

Les secrets de tests doivent être explicitement des fixtures non réelles.

Ne jamais utiliser :

un wallet personnel ;
une seed Mainnet ;
une clé provenant d'un .env opérateur ;
un fichier .kspwallet réel.

Si une fixture déterministe est nécessaire, son caractère test-only doit être évident et elle ne doit jamais être utilisable comme secret de production recommandé.

Les test vectors d'interopérabilité peuvent publier volontairement :

password VIEW connu
password OWNER connu
secret test-only connu
Pubkey/alias/notes attendus
bytes/JSON .kspwallet attendus

uniquement lorsqu'ils sont explicitement réservés aux tests et documentés comme tels.

11. Dépendances

Toutes les dépendances tierces communes sont déclarées au Cargo.toml racine sous [workspace.dependencies].

Les membres consomment :

<dependency>.workspace = true

Éviter :

crypto maison ;
deux crates concurrentes pour la même primitive sans justification ;
stack async ou sérialisation supplémentaire sans besoin ;
client Solana RPC ;
dépendance Tauri ;
Config ;
Store.

Toute nouvelle dépendance liée au secret doit être auditée au minimum sur :

maintenance actuelle
version Rust/MSRV pertinente
features par défaut
unsafe/transitifs importants
zeroize support
format/compatibilité
audit de sécurité disponible
interopérabilité externe
duplications cargo tree

12. Async / sync

Les opérations I/O doivent respecter la règle async-first du projet.

Le plan doit néanmoins distinguer :

calcul CPU KDF potentiellement coûteux ;
opérations filesystem ;
signature CPU locale.

Ne pas bloquer naïvement un runtime async avec une dérivation de clé coûteuse. Décider explicitement si l'API de bas niveau est sync avec wrapper async, utilise spawn_blocking, ou adopte une autre frontière cohérente.

Ce choix doit rester compatible avec l'usage futur Tauri sans introduire Tauri dans Wallet.

13. Projection après autorisation

Wallet doit pouvoir fournir une représentation sûre destinée aux consommateurs autorisés qui n'ont besoin que des metadata.

Wallet verrouillé :

ne révèle pas Pubkey
ne révèle pas alias
ne révèle pas notes

Avec VIEW ou OWNER :

Pubkey
alias
notes
format/version si pertinent
état/capability sans secret

Avec OWNER seulement :

capacité de signature
administration metadata/key slots

La terminologie « identité publique » signifie que la Pubkey elle-même n'est pas un secret blockchain, mais le fichier .kspwallet ne doit pas la révéler à un lecteur non authentifié par défaut.

14. Hors périmètre `0.2.5`

Sont exclus sauf décision de rescoping explicite pendant le gate pre.001 :

ksp-app-wallet-desk
lecture réseau du solde
HTTP/WebSocket/gRPC
WalletPolicy
execution policy
construction/simulation/envoi de transaction
Store
seed phrase UI
hardware wallet / Ledger
remote signer
browser extension
mobile app
cloud key management
custody service
trading
recovery slot réellement implémenté
hardware/automation key slot réellement implémenté

Les futurs rôles/key slots peuvent être anticipés structurellement sans être implémentés en V1.

Les pistes d'import/export peuvent être étudiées sans rendre leurs applications/providers propriétaires du cœur Wallet.

15. Relation avec `0.2.6 — Wallet Desk`

0.2.6 doit pouvoir composer :

Config
  + ksp-wallet-lib
  + ksp-onchain-transport-lib
  + ksp-logging-lib
  -> ksp-app-wallet-desk

Le premier flux réseau attendu peut devenir :

sélectionner un .kspwallet
-> déverrouiller VIEW ou OWNER
-> obtenir la Pubkey
-> getBalance via Transport HTTP
-> afficher identité + alias/notes + solde selon capability

Aucune logique réseau nécessaire à ce flux ne doit remonter dans ksp-wallet-lib.

16. Prévision souple des prereleases

Prévision initiale à réévaluer par pre.001 :

pre.001  audit bot3 + crypto/deps actuelles + threat model + VIEW/OWNER + format/API + sizing
pre.002  crate foundation + capabilities VIEW/OWNER + erreurs + canaries architecture
pre.003  enveloppe/key slots .kspwallet + format/version + KDF/AEAD/wrapping + test vectors
pre.004  compartiments metadata/secret + create/open VIEW/OWNER + persistence atomique/no-clobber
pre.005  signature + administration alias/notes + rotations VIEW/OWNER + read-only cryptographique si retenu
pre.006  architecture import/export + premier(s) format(s) réellement retenu(s)
pre.007  security/interoperability/compliance audit + format spec + README/USAGE + graphes
pre.008  clôture candidate + documentation finale + prompt 0.2.6 — Wallet Desk
rel.001  publication strictement publicationnelle

Cette prévision est souple.

Si l'architecture VIEW/OWNER, l'authentification metadata ou la persistence exige une tranche supplémentaire, ajouter une prerelease/fix plutôt que compresser les validations.

Si pre.001 conclut qu'un format/import particulier doit être reporté, le report doit être explicite et ne doit pas affaiblir les garanties du format natif.

17. Validation continue

Après chaque changement Rust :

cargo fmt --all
cargo check --workspace
cargo clippy --workspace --all-targets

Pendant le développement :

cargo test -p ksp-wallet-lib

Les checkpoints de clôture doivent également réauditer :

cargo tree / duplications crypto
frontières de dépendances
absence d'accès environnement direct
absence de secrets dans logs/errors/debug
interop test vectors

31 KiB Raw Blame History

Prompt de démarrage 0.2.5 — Wallet foundation