fix(#546): render the HTTPS onion vhost on the run that captures the address#573
Merged
Merged
Conversation
…address generate_caddyfile only emits the https://<onion> SNI vhost (#360) once the address is captured, but every capture leg ran AFTER the Caddyfile was rendered with the placeholder and never re-rendered: apply's post-up capture only refreshed .env (and the next apply no-ops on an unchanged config), upgrade's capture leg (#356) had the same hole, and rotate-dashboard-onion restarted caddy without regenerating at all — serving the retired onion's vhost with none for the new address. All three legs now regenerate the Caddyfile and restart caddy the moment the address lands. Setup is unaffected: provision_tor captures before setup renders. Closes #546 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #546
The
https://<onion>SNI vhost (#360) is only emitted bygenerate_caddyfileonce the dashboard onion address is captured — but every capture leg ran after the Caddyfile had been rendered with the placeholder, and none re-rendered it:.envonly; the next apply hit the "No configuration changes detected" early return before ever reachinggenerate_caddyfile, so the vhost never appeared (stock Tor Browser's HTTPS-First upgrade then fails the TLS handshake — dashboard unreachable over the onion).rotate-dashboard-onioncrashes withHOST_IP: unbound variable; onion address not captured when enabled viaupgrade#356 capture leg had the identical hole (found during review; the delegated agent's fix covered apply+rotate, the session lead added the upgrade leg).All three legs now run
generate_caddyfile+docker compose restart caddythe moment the address lands. Setup is unaffected (provision_torcaptures before setup's render). The lying comment ("adds HTTPS on the next apply") is fixed.Tests (tier 1): black-box
applyandrotate_dashboard_oniondrives withgenerate_caddyfileleft REAL, asserting on the actual Caddyfile (vhost appears in the same apply run; rotate drops the old vhost and adds the new); shadow-drivenstack_upgradecountinggenerate_caddyfilecalls (2 with capture, 1 without).Revert-proof (pithead fix dropped, tests kept):
✗ upgrade capture regenerates the Caddyfile,✗ apply: HTTPS onion vhost appears in the SAME apply run,✗ rotate drops the retired onion's HTTPS vhost,✗ rotate adds the new onion's HTTPS vhost in the same run— all pass with the fix restored.Ponytail review: one finding (duplicated shadow helper) — folded into the existing
upg_capturehelper, −20 lines.CHANGELOG: Unreleased entry included.
🤖 Generated with Claude Code