Harden operator-set target headers (closes #233)

Three findings from the review of the per-target request headers
feature, plus the follow-up they raised about the inbound headers
the same delivery path forwards.

One rule now governs every header a delivery carries on someone
else's behalf: a redirect hop that leaves the origin the target
names carries none of them. That covers the operator's configured
headers and the inbound event headers forwarded from the sender
alike. net/http withholds only Authorization and Cookie across a
host change, so an operator's X-Api-Key or a sender's
X-Hub-Signature would otherwise follow a 302 to a host nobody
configured. Redirects are still followed — refusing them would
break every destination that legitimately redirects and would
record the 3xx as the delivery's result — but a hop to another
host, another port, or down from https to http drops the lot. The
shared SSRF-safe transport is kept on that client, so each hop is
still dialled through the private-IP guard.

The set to strip is not a name list. applyRequestHeaders now
returns the canonical names of everything it applied on the
sender's or operator's behalf, and the redirect policy strips
exactly that, so a header added to the forward set is covered
without a second edit. Content-Type and User-Agent are the
delivery path's own rather than anyone else's, and both are
excluded from that set so they always travel: Content-Type is set
from the event and a 307 preserves the body across hosts, so it
has to stay typed, and User-Agent is overwritten with this
delivery path's own after the forwarded headers are applied, so
the sender's never reaches the wire and stripping it off-origin
would only substitute net/http's default.

The origin comparison no longer collapses two IPv6 origins into
one. Hostname() unwraps a literal's brackets, so re-appending the
port with a bare colon rendered https://[2001:db8::1]:8080 and
https://[2001:db8::1:8080] identically — a different address on a
different port passing as the same origin. The port is joined with
net.JoinHostPort, and both spellings are in TestSameDeliveryOrigin.

The ten-hop cap gains a regression test. Installing a CheckRedirect
is precisely what discards net/http's own limit, so a
self-redirecting destination is driven through the policy and
asserted to stop after exactly ten requests with the sentinel
surfacing to the caller.

Trailer joins the reserved names. net/http strips it from the
request it writes, so a configured one was accepted, stored, and
provably never sent.

The invalid-header-name error no longer quotes the text before the
first colon. That text is only a name if it parses as one; when it
does not, a pasted value whose own colon split the line put half a
token into a 400 body. TestParseTargetHeaders_ErrorsNeverQuoteAValue
asserted this invariant while only exercising the after-the-colon
case, and now covers the before-the-colon one.

README documents the http target's config keys, the 300-second
timeout ceiling, the reserved-header list and the redirect
behaviour as one rule over both header classes, including that the
drop is per hop rather than permanent: net/http re-copies the
initial request's headers each hop, so a chain returning to the
configured origin carries them again, exactly as it treats
Authorization. It also records what following a 301, 302 or 303
costs, since that is net/http's own behaviour and the decision to
follow redirects is what buys it: the POST becomes a GET and the
event body and its Content-Type are dropped, so the destination
the chain ends at receives no event while the delivery is still
recorded Delivered. The edit form's hint gains Trailer and the
redirect note.

Closes #243

TODO.md

@@ -18,52 +18,68 @@ Issue branches do NOT touch this file — the manager maintains it on
 
 # Status
 
-1.0.0 is complete: 55 closed, 0 open. `next` (6874059) is 62 commits
-ahead of `main` and a strict fast-forward. No git tags exist yet.
+pre-1.0. No git tags exist. `main` (4f5ecb1) is a working webhook proxy
+with auth, CSRF/SSRF protections, login rate limiting, Slack target,
+event retention (#63), the database archiving target (#43), the admin
+password change flow (#65), policy compliance (#6), pinned lint tooling
+(#55), and fail-loud configuration parsing (#80).
 
-The bar was not "the milestone is empty" but "sneak can deploy this and
-use it in low-volume production". Every gap the deployability audit
-named against that bar is now closed:
+`next` is green — verified both by CI and by cache-defeated container
+runs (`docker build --no-cache-filter=lint --no-cache-filter=builder`) —
+but the **1.0.0 milestone is no longer complete**. It was reopened on
+2026-08-20 by a code-level deployability audit that ran the service end
+to end (verdict:
+https://git.eeqj.de/sneak/webhooker/issues/33#issuecomment-66686).
 
-- `DATA_DIR` locking, so two instances cannot both deliver
-  (https://git.eeqj.de/sneak/webhooker/issues/201)
-- shutdown on listener failure, rather than a live non-serving process
-  (https://git.eeqj.de/sneak/webhooker/issues/200)
-- inbound signature verification
-  (https://git.eeqj.de/sneak/webhooker/issues/67)
-- per-attempt delivery detail in the event log
-  (https://git.eeqj.de/sneak/webhooker/issues/202)
-- replay of a terminally failed delivery
-  (https://git.eeqj.de/sneak/webhooker/issues/203)
-- `ALLOWED_EGRESS_CIDRS`, an allowlist escape hatch for the SSRF guard
-  (https://git.eeqj.de/sneak/webhooker/issues/204)
-- the three credential exposures
-  (https://git.eeqj.de/sneak/webhooker/issues/205,
-  https://git.eeqj.de/sneak/webhooker/issues/206,
-  https://git.eeqj.de/sneak/webhooker/issues/207)
+The bar for 1.0 is not "the milestone is empty" but "sneak can deploy
+this and use it in low-volume production". The audit found the gap
+between those two: two instances on one `DATA_DIR` both deliver
+(reproduced), a failed listen leaves a live non-serving process that
+restart policies never fire on, there is no inbound authentication of
+any kind, delivery failures render as a bare word with no status code or
+error, a terminally failed delivery can never be replayed, the SSRF
+blocklist has no escape hatch so the proxy cannot forward to your own
+network at all, and target credentials leak into the per-webhook event
+databases.
 
-One caveat on reading a green check: a docs-only commit deliberately
-replays from the layer cache
-(https://git.eeqj.de/sneak/webhooker/issues/119), so a green status on
-such a commit evidences a replay rather than an executed run. A code
-commit invalidates the `COPY` layer and genuinely executes.
+One caveat on reading a green check, narrower than it used to be. A
+docs-only commit deliberately replays from the layer cache (#119), so a
+green status on such a commit evidences a replay rather than an executed
+run; a code commit invalidates the `COPY` layer and genuinely executes.
+Superseded runs are no longer the hazard they were: before #152 they
+were recorded as `skipped` and rolled up green, and before #119 a warm
+layer cache let the gate report success without executing anything,
+replaying the previous build's console log so the lie looked like a real
+run. Both are fixed. Note: `TODO.md` was deliberately
+deleted from this repo in f9a9569 (2026-03-01, #6); its content was
+folded into the README TODO section, which this draft reconstructs as
+of 2026-07-06.
 
 # Next Step
 
-Merge the milestone PR (https://git.eeqj.de/sneak/webhooker/pulls/111)
-and tag `v1.0.0`. It is `merge-ready` and assigned to sneak; nothing
-else gates it.
+Clear the reopened 1.0.0 milestone. The milestone PR
+(https://git.eeqj.de/sneak/webhooker/pulls/111) is held: it carries a
+`WIP: ` prefix, no labels and is assigned to `clawbot`, and it stays
+that way until the milestone is empty. Correctness first — the
+duplicate-delivery lock and the listen-failure shutdown — then the
+operability gaps that make the service usable in production, then the
+three credential exposures.
 
-Post-1.0 follow-ups are open, none blocking the tag:
-https://git.eeqj.de/sneak/webhooker/issues/245,
-https://git.eeqj.de/sneak/webhooker/issues/246,
-https://git.eeqj.de/sneak/webhooker/issues/247 and
-https://git.eeqj.de/sneak/webhooker/issues/248. Also still open and
-unmilestoned: https://git.eeqj.de/sneak/webhooker/issues/193 (a design
-question, not a defect), https://git.eeqj.de/sneak/webhooker/issues/198
-(`make test` is past the org 20s target) and
-https://git.eeqj.de/sneak/webhooker/issues/212 (encrypting target config
-at rest).
+Three items belong to the owner, none of them blocking. #150 was decided
+by the manager rather than left to stall the queue and is flagged on the
+issue for reversal if that call was wrong. #112 (whether `Completed
+Steps` should exist at all, given it once conflicted on every unit) is
+unanswered; the provisional ruling in force is that issue branches do
+not touch this file. #198 records that `make test` is past the org 20s
+target — 46s of test execution inside a 62.8s CI layer — and turns on
+which quantity the 60s hard cap governs; it is scoped as the improvement
+bug the 20-60s band requires, and should be milestoned instead if the
+cap is read as covering the whole invocation.
+
+After the tag, the largest open cluster is the unmilestoned follow-up
+backlog these units generated: #183, #184, #185, #190, #191, #193, #198,
+#211 and #212 (encrypting target config at rest, split out of the
+credential-leak fix because it needs a key-rotation and re-wrap story).
 
 # Completed Steps
 
@@ -292,16 +308,14 @@ at rest).
 
 # Future Steps
 
-- Delivery status and retry management UI. Replay of a terminally
-  failed delivery and per-attempt detail already landed
-  (https://git.eeqj.de/sneak/webhooker/issues/203,
-  https://git.eeqj.de/sneak/webhooker/issues/202)
+- Manual event redelivery from the web UI — the "Replay" capability the
+  README describes as planned. No redelivery code exists anywhere in the
+  tree; events are stored in full, which is all it would be built on
+- Delivery status and retry management UI
 - Per-webhook rate limiting in the receiver handler (per-webhook config
   plus handler enforcement; global limits must not apply to receiver
   endpoints)
-- Stripe HMAC signature verification. The GitHub and GitLab schemes
-  landed with inbound verification
-  (https://git.eeqj.de/sneak/webhooker/issues/67)
+- Webhook signature verification for GitHub and Stripe HMAC formats
 - API key authentication for programmatic access (APIKey model exists;
   Bearer token middleware does not)
 - REST API v1
@@ -311,10 +325,9 @@ at rest).
     - OpenAPI specification
 - Analytics dashboard: success rates, response times, volume
 - A remember-me option at login
-- Password reset flow for a forgotten password over the web. The
-  authenticated password *change* flow already landed, and a lost
-  password is recoverable from the console with `webhooker resetpw`
-  (https://git.eeqj.de/sneak/webhooker/issues/208)
+- Password reset flow for a forgotten password. The authenticated
+  password *change* flow already landed on `main` (#65); reset does not
+  exist
 - Later, nice to have
     - email delivery target type
     - SNS and S3 delivery targets