Repository navigation
Standalone stratum-auth must isolate the authenticated fixture pool #570
Description
Found while validating #559 / PR #561. This is a separate harness prerequisite, not a credential-transport change.
tests/e2e-pithead.sh requires PITHEAD_URL in preflight, but standalone phase_stratum_auth edits only .pools[0].pass; only phase_connect selects .pools[0].url. The runner invokes requested phases separately and each invocation restores its snapshot, so adding a separate connect phase cannot establish the target for the subsequent auth invocation. Existing secondary pools can also provide work independently of the authenticated fixture.
Retained job 2093@05341b4ad9f0b9c0b55f95669d28d01722740730 ran access-tokens,stratum-auth: the right-password mining assertion passed, but wrong-password rejection failed. Its fixed-schema diagnostics recorded mining work and accepted shares with no classified authentication errors during the wrong-password window. Full status, log and both artifacts were read; baseline and rig restoration passed. Job 2086@5705bc8f74c4544a291dceef3813ac91b18bf564 had the same rejection failure. These observations do not prove which endpoint supplied the work; the source-level targeting gap is independently established.
Acceptance criteria:
- Make the narrow Stratum phase select and isolate the authenticated fixture supplied by
PITHEAD_URL, without changing payout identity or exposing credentials/topology in external arguments or public diagnostics. - Preserve required-password refusal, acceptance, rejection/no-work, recovery and byte-identical EXIT restoration, including error paths.
- Add hardware-free regressions starting from a different primary pool and a usable fallback, which fail without fixture isolation; correct the phase documentation.
- Prove actual acceptance/rejection/recovery with a pushed-SHA narrow
tier4-e2erun, including verified restoration.
This prevents PR #561 from obtaining trustworthy Stratum proof. After this prerequisite merges, resume #559, incorporate the base and submit both touched phases again. Do not weaken the rejection assertion or enlarge its deadline as a substitute for selecting the fixture.
Activity
pithead-developer commentedon Oct 3, 2026
Moved into v2 - appliance because #559 depends on this issue in the release dependency chain.
pithead-developer commentedon Oct 3, 2026
Blocked on bench preflight proof
bench-ci#1183 prevents completing the hardware acceptance criteria. Job
2094@833b338e5ee2e6758e94e7509ea338711f64615dended with a preflight Tor egress verification error before the Stratum harness ran. Full status/log and the empty artifact inventory were read; baseline verification and rig restoration succeeded, but no authentication assertions executed.Draft PR #572 contains fixture isolation, secret-safe setup diagnostics, corrected documentation and regressions covering targeting, fallbacks and all three apply-failure stages. The focused driver passed 124 assertions; pinned focused lint, topology and exact file-budget gates passed, and repeated verifier/security reviews are clean. Six GitHub checks have passed; Test suite and Coverage are pending on the current head. No local container/full-suite PASS is claimed.
Bench maintainers must diagnose and resolve #1183 through the managed workflow. When it closes, resume with a fresh narrow pushed-SHA Stratum job and read its full logs/artifacts, confirming acceptance, rejection/no-work, recovery and verified restoration before readiness. No identical retry or manual bench action was performed. The stale client recurrence is recorded on bench-ci#1148; a current scratch client retrieved the supported evidence without changing the submitted job.
pithead-developer commentedon Oct 3, 2026
Blocked on p2pool-starter-stack/bench-ci#1183. Draft PR #572 contains fixture isolation, corrected documentation and regressions; 124 focused assertions pass and verifier/security reviews are clean. Bench-ci#1183 blocks hardware proof: job 2094@833b338e5ee2e6758e94e7509ea338711f64615d failed preflight before authentication ran, although restoration passed. Bench maintainers must resolve the preflight failure, then a fresh narrow run must prove acceptance, rejection and recovery; evidence and blocker comments are published.
The runner resumes this issue when that one closes.
VijitSingh97 commentedon Oct 3, 2026
Owner ruling 2026-10-03 21:10Z: test-harness-only work changes nothing in the 2.0.0 RC, the soak or GA, so it moves from v2 - appliance to v2.x - post-GA. The RC was cut at 459847441a9f and its release gate runs targeted mode, per docs/dev/releasing.md. PR #572 touches only tests/ and does not move the RigForge pin (f5ff047). Its hardware proof is devops job 2100 (bench-ci#1183).
pithead-developer commentedon Oct 3, 2026
Moved into v2 - appliance because #559 depends on this issue in the release dependency chain.
VijitSingh97 commentedon Oct 3, 2026
Back in v2 - appliance by the runner's security-chain rule. Security fix rigforge#559 (credentials in harness process arguments) depends on this. Under the 2026-10-02 ruling, security remediation keeps moving through the freeze, so its blockers stay workable in the gate. That supersedes the operator's 21:10Z move. This is still test-harness work and changes nothing in the 2.0.0 RC, the soak or GA.
pithead-developer commentedon Oct 3, 2026
Merged in #572.