v0.2.9-pre.013-fix.002
This commit is contained in:
176
deltas/0.2.9/pre.013-fix.002.md
Normal file
176
deltas/0.2.9/pre.013-fix.002.md
Normal file
@@ -0,0 +1,176 @@
|
||||
<!-- file: deltas/0.2.9/pre.013-fix.002.md -->
|
||||
<!-- version: 1 -->
|
||||
|
||||
# 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.
|
||||
Reference in New Issue
Block a user