# Delta `0.2.9-pre.013-fix.002` — authentification PublicNode Yellowstone ## 1. Base ```text livraison : 0.2.9-pre.013-fix.001 Cargo : 0.2.9-pre.13.fix.1 ``` Le second smoke opérateur invalide l'hypothèse retenue dans `fix.001` : ```text Mainnet SubscribeOpen -> PERMISSION_DENIED Testnet SubscribeOpen -> PERMISSION_DENIED ``` Les deux endpoints sont donc atteignables au niveau TLS/gRPC mais refusent aussi la surface `Subscribe` sans autorisation. ## 2. Diagnostic retenu Les éléments concordants sont désormais suffisants pour traiter PublicNode Yellowstone comme une surface à personal token : ```text provider = publicnode auth wire = metadata ASCII x-token secret = oui URL = sans credential ``` La page PublicNode expose les endpoints Yellowstone Mainnet/Testnet. Une capture récente de la page PublicNode expose en outre un lien `Get token` vers le flow Allnodes `https://www.allnodes.com/publicnode`. Des implémentations Yellowstone récentes visant explicitement PublicNode rapportent le même comportement `PERMISSION_DENIED` sans personal token et utilisent `x-token`. Le provisioning effectif du token reste un gate externe/opérateur : KSP ne génère, ne devine et ne versionne aucun credential provider. ## 3. Config V3 Les profils : ```text publicnode_mainnet publicnode_testnet ``` conservent leurs URLs TLS sans secret et ajoutent chacun : ```json "secret_metadata": [ { "key": "x-token", "value": "${KSP_SECRET_PUBLICNODE_GRPC_X_TOKEN}" } ] ``` L'absence de `KSP_SECRET_PUBLICNODE_GRPC_X_TOKEN` rend donc volontairement le profil PublicNode explicite non résolvable au lieu d'envoyer silencieusement une requête anonyme vouée à `PERMISSION_DENIED`. `.env.example` inventorie la variable sans valeur réelle. ## 4. Canari Config Le canari des profils PublicNode fournit un canary secret via `ConfigEnvironment`, vérifie : ```text Mainnet/Testnet exacts metadata count = 1 metadata key = x-token metadata class = secret Debug = sans canary Transport validation = PASS ``` Les règles génériques V3 de provenance `secret_metadata` restent inchangées. ## 5. Smoke Transport pur Le smoke reste dans `ksp-onchain-transport-lib` et ne dépend pas de Config. Pour ne pas violer la frontière `Transport -X-> process environment` et pour ne pas exposer le token dans les arguments/process list, le harness lit une seule ligne secrète depuis son `stdin`. Le même personal token est réutilisé par les deux tests Mainnet/Testnet via un `OnceLock`, puis injecté avec : ```text YellowstoneGrpcMetadataEntry::secret("x-token", ...) ``` Le token n'est jamais loggé et un canari runtime vérifie qu'il n'apparaît pas dans `Debug`. Le smoke continue de valider : ```text TLS Subscribe bidirectionnel filtre slots première update Slot slot > 0 close borné ``` ## 6. Signal de version Le correctif modifie Config runtime et un test Rust : ```text workspace.package.version = 0.2.9-pre.13.fix.2 commit attendu = v0.2.9-pre.013-fix.002 ``` ## 7. Gate opérateur ### 7.1 Déterministe ```bash cargo fmt --all python3 scripts/audit_rust_workspace_rules.py python3 scripts/audit_markdown_tables.py README.md RULES.md ROADMAP.md CHANGELOG.md docs prompts crates deltas/0.2.9 cargo check --workspace cargo clippy --workspace --all-targets cargo test -p ksp-config-lib cargo test -p ksp-onchain-transport-lib cargo test -p ksp-core-lib --test workspace_dependencies ``` ### 7.2 Provisioning externe Obtenir le personal token PublicNode via le flow Allnodes/PublicNode : ```text https://www.allnodes.com/publicnode ``` Ne jamais le committer, le coller dans l'URL ou le passer comme argument de processus. ### 7.3 Smoke live Le token est saisi dans une variable shell non exportée, puis envoyé au harness via stdin : ```bash read -rsp 'PublicNode Yellowstone x-token: ' PUBLICNODE_TOKEN echo printf '%s\n' "$PUBLICNODE_TOKEN" | cargo test -p ksp-onchain-transport-lib --test yellowstone_publicnode_smoke -- --ignored --nocapture --test-threads=1 unset PUBLICNODE_TOKEN ``` Attendu après provisioning valide : ```text 2 passed 0 failed 0 ignored ``` Si le provisioning provider est inaccessible ou si le token reste refusé, le smoke reste `EXTERNAL BLOCK`; ne pas transformer ce blocage en faux PASS. ### 7.4 Graphes et workspace ```bash cargo tree -p ksp-onchain-transport-lib cargo tree -p ksp-onchain-transport-lib --duplicates cargo tree --duplicates cargo test --workspace ``` ## 8. Frontières Ce fix reste strictement dans le couloir technique/live de `pre.013` : ```text aucun README/USAGE modifié aucun plan/validation modifié aucun CHANGELOG/ROADMAP modifié aucun prompt modifié aucun provider-specific engine ajouté aucun credential committé ``` La prochaine tranche reste `0.2.9-pre.014` de réconciliation documentaire uniquement après fermeture du gate technique, ou après qualification explicite d'un blocage provider externe.