Fourth and final step of PRD 0005. Two new end-to-end tests that
exercise the full chain agent -> mitmproxy(bump) -> addon ->
pipelock -> upstream and pin the two paths the addon implements.
- test_mitmproxy_blocks_secret_https_post: HTTPS variant of the
existing test_pipelock_blocks_secret_post. Posts a credential
pattern in the body over HTTPS through the bottle. mitmproxy
bumps the CONNECT (the agent trusts the per-bottle ephemeral CA
installed by provision_ca), the addon forwards the decrypted
request to pipelock, pipelock returns 403 with the known
`blocked: ...` body shape, and the addon short-circuits the
flow with status=403 + X-Pipelock-Bridge: block. The two-axis
assertion (status + header) proves the addon-mediated path is
what produced the block, not some other layer.
- test_mitmproxy_allows_normal_https: hits raw.githubusercontent.com
(a baked-in allowlist host) over HTTPS through the bottle.
Verifies the addon's allow path: mitmproxy bumps, addon
forwards to pipelock for the scan, pipelock allows, mitmproxy
proceeds to the real upstream, response comes back through. The
absence of X-Pipelock-Bridge on the response is the signal that
the addon didn't short-circuit. Body length sanity-checks that
the response is real upstream content, not a synthesized stub.
Both probes are stdlib-only Node (http.request CONNECT + tls.connect
on the tunneled socket) — pulling in undici as a dep would be the
clean way to do HTTPS-through-proxy but is out of scope.
The earlier integration tests still pass with mitmproxy in path:
their assertions hold under the new topology, though their semantic
coverage shifts (e.g. test_pipelock_allow_node now exercises
mitmproxy's CONNECT-200 path rather than pipelock's host allowlist
on CONNECT). Updating those tests is a follow-up.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
