Skip to content

TLS13-C11: make the consumer's target a parameter, and gate the live hop - #1291

Merged
drawmeanelephant merged 2 commits into
mainfrom
agent/autocoder/tls13-c11
Sep 15, 2026
Merged

drawmeanelephant merged 2 commits into
mainfrom
agent/autocoder/tls13-c11

Conversation

@drawmeanelephant

Copy link
Copy Markdown
Owner

Two changes that belong together because one enables the other.

1. FETCHS.BIN takes its target from argv

exec FETCHS.BIN [ipv4 [port [server-name]]], defaulting to 10.0.0.2:443 as leaf.example.com.

A hardcoded 443 meant any live test needed the runner to run as root — which is how a test quietly stops testing.

The rules live in lib/tls/target.zig rather than in the binary, because the binary links the kernel ABI and cannot be host-tested. Dotted-quad parsing rejects empty octets (including a trailing dot), a fifth octet, values over 255, and anything that is a name; ports reject 0, overflow and junk.

zig test user/src/lib/tls/target.zig  -> 3/3 pass
zig build test                        -> 200/200 steps, 3599/3599 tests
zig build                             -> FETCHS.BIN, 239176 B image, 3 PT_LOAD segments

2. tools/gate/specs/live-tls13.spec — the class-B gate

The hop the interop matrix cannot reach: a host-side responder (tlsresponder.py, #1290) serves the fixture identity on 0.0.0.0:24533; the guest execs FETCHS.BIN against the gateway; the serial must carry the whole chain of events through to the response body. The responder's anchor is byte-identical to the vendored blob FETCHS.BIN carries, so the guest validates against its own pinned root rather than a test-only bypass.

This spec is an experiment, not a proven artifact

It could not be run before commit — a boot is exactly what it needs. It is here because the only way to learn whether the guest-side plumbing lines up is to run it in CI, where VZ exists.

If it fails, the failure is the finding. Known unknowns, in the order I'd expect them to bite:

  1. Whether the guest's TCP can dial the host gateway on a high port (the 10.0.0.2 convention from fetch.zig/download.zig).
  2. Whether ui.sys_time() returns a real epoch under VZ — FETCHS.BIN deliberately refuses to check validity without a clock rather than guessing.
  3. Whether the responder outlives vgate_setup_python and the boot.

If it reds, the spec comes out and this PR keeps the argv work, which stands on its own.

Two changes that belong together because one enables the other.

1. FETCHS.BIN takes its target from argv -- `exec FETCHS.BIN [ipv4 [port
   [server-name]]]`, defaulting to 10.0.0.2:443 as leaf.example.com. A
   hardcoded 443 meant any live test needed the runner to run as root, which is
   how a test quietly stops testing.

   The rules live in lib/tls/target.zig rather than in the binary, because the
   binary links the kernel ABI and cannot be host-tested. Dotted-quad parsing
   rejects empty octets (including a trailing dot), a fifth octet, values over
   255, and anything that is a name; ports reject 0, overflow and junk. Nine
   cases, including the ones a naive `split('.')` gets wrong.

2. tools/gate/specs/live-tls13.spec -- the class-B gate for the hop the interop
   matrix cannot reach. A host-side responder (tlsresponder.py, C10) serves the
   fixture identity on 0.0.0.0:24533; the guest execs FETCHS.BIN against the
   gateway; the serial must carry the whole chain of events through to the
   response body. The responder's anchor is byte-identical to the vendored blob
   FETCHS.BIN carries, so the guest validates against its own pinned root
   rather than a test-only bypass.

   This spec is an experiment, not a proven artifact: it could not be run
   before commit, since a boot is what it needs. It is here because the only
   way to learn whether the guest-side plumbing lines up is to run it in CI,
   where VZ exists. If it fails, the failure is the finding.

Evidence:
  zig test user/src/lib/tls/target.zig -> 3/3 pass
  zig build test -> 200/200 steps, 3599/3599 tests
  zig build      -> FETCHS.BIN converts, 239176 B image, 3 PT_LOAD segments
The GF1 registration guard requires a new spec to ship with a regenerated
report; CI caught it, correctly. Ran tools/inventory-gates.sh; --check is green
again (226 specs, 8 declared exemptions, 2 excused violations unchanged).

The spec itself passed the shape guards on the first attempt -- spec-order
reported OK, meaning no ungated echo-ended run and no file op racing an exec.
@drawmeanelephant
drawmeanelephant merged commit 4d42cff into main Sep 15, 2026
9 checks passed
@drawmeanelephant
drawmeanelephant deleted the agent/autocoder/tls13-c11 branch September 15, 2026 03:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant