4.9 KiB
Delta 0.2.9-pre.013-fix.002 — authentification PublicNode Yellowstone
1. Base
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 :
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 :
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 :
publicnode_mainnet
publicnode_testnet
conservent leurs URLs TLS sans secret et ajoutent chacun :
"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 :
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 :
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 :
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 :
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
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 :
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 :
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 :
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
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 :
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.