[earakely-scale]

What changes

Since #649, a computer's session programs read the universe's time. Chromium, Java and an official Node build check a site's certificate against that time with their own TLS, which the OpenSSL shim (#639) can't reach. So with the clock months back or ahead, they refuse live sites. This adds an egress proxy to the ubuntu-24.04 base, on real time, that every session program goes out through (FD-5478).

What it does with each connection:

• It serves CONNECT and absolute-form HTTP on 127.0.0.1:3128. It runs as its own user, agentenv-egress, under root's supervisord. The clock library leaves that user on real time. There are no firewall rules and no NET_ADMIN, so it runs on any provider.
• Pass through: when the clock is unarmed, or when every universe a client may check against is more than 8 days inside the dates every certificate of the site's verified chain shares, it relays the client's bytes untouched. It also passes through when its own probe handshake doesn't finish, as with a site asking for the client's certificate, so the client answers it itself. Each of a site's addresses is decided by its own probe, cached per address: one that doesn't answer is passed over, one already found working is tried first, and a connection goes only to an address a probe judged. The universes a client may check against are now, the universe at the clock's anchor, and, for 30 s after a change, the one it left.
• Intercept: otherwise it verifies the site against real time and the image's public roots. It then hands the client a certificate from the computer's own CA, valid from 1950 to 9999, the same window feat(computers): routed sites' certificates hold at any date a computer's clock can show (FD-5480) #654 gave routed sites. A site that doesn't verify is handed on under a CA nothing trusts, so the client refuses it as it would the site.
• The client's own fingerprint: the proxy's handshake with the site uses uTLS, built from the client's own ClientHello. The site sees the client's fingerprint and ALPN offer either way, and h2 runs end to end.
• Destinations: it refuses every destination that isn't global (RFC 1918, loopback, link-local, CGNAT, the metadata address and IANA's other special blocks). It tries each of a name's addresses in turn, IPv4 first. It allows a routed site's name, which the hosts file maps to the site proxy.
• Plain HTTP: it forwards the client's own head, rewriting only its request line and the proxy-only headers, then relays both ways. An upgrade, such as a WebSocket, keeps its Connection and Upgrade headers; any other request closes once answered, and an upload waiting on 100 Continue gets it at once.
• Logging: one JSON line per connection, in root's supervisord log, which the session user can't read. Its probe and leaf caches are bounded (4,096 each).

The CA and the session's settings:

• Init mints the CA at boot (egress boot), once per computer. Its key is readable by agentenv-egress alone.
• Boot trusts the CA in the system store, agent-env's trust files (/etc/agentenv/ca.pem, ca-bundle.pem), every certifi bundle, every JDK's store and the session user's NSS database. A step that fails fails init, naming it, except a certifi bundle or a JDK's store an app brings: one that can't take the CA is named among the boot's warnings, and the computer boots.
• The session's supervisord, and a login shell through /etc/profile.d, set:
  • HTTP(S)_PROXY, ALL_PROXY and NO_PROXY (localhost and host.docker.internal);
  • SSL_CERT_FILE, REQUESTS_CA_BUNDLE and NODE_EXTRA_CA_CERTS, at agent-env's trust files, as the local provider already did;
  • JAVA_TOOL_OPTIONS with Java's proxy properties, and NODE_USE_ENV_PROXY=1 for Node's fetch.

agent-env's own servers go direct. The computer's driver and app servers (computer.serve, computer.serve_app) run on real time, so as they start they call agentenv_protocol.transfers.direct(): their own transfers, recordings, snapshots and files by grant, reach the object store directly, never through the proxy, which would refuse a store or gateway at a private address, still trusting the CAs SSL_CERT_FILE names. The programs they start keep the session's proxy settings, since the environment is untouched. (The driver's sync_time already read the gateway directly.)

How it's built: one Go program, artifacts/ubuntu-24.04/egress/, decided on FD-5478 instead of the prototype's Python proxy plus Go helper. The base's Dockerfile builds it in a stage of its own, which runs go vet and its tests first, so no Go toolchain is left in the image. make egress-test runs gofmt, go vet and its tests under -race in that same Go image, so it needs Docker, not Go, and CI runs it as a new egress job, which pulls the image from mirror.gcr.io first. egress/README.md says what runs where, what the proxy does with each kind of connection, and its log's fields. go.sum pins its modules, Dependabot's new gomod entry keeps them current, and THIRD_PARTY_NOTICES lists them.

Behaviour to know about

• Chromium on the desktop now goes through the proxy too. It reads the environment's proxy settings under XFCE. FD-5481 still adds its managed proxy policy.
• Clients that ignore proxy settings still go direct. That includes an older Node's fetch, which predates NODE_USE_ENV_PROXY. They check certificates against universe time unless they use the system's OpenSSL, which the shim covers.
• A computer with no network now answers 502 through the proxy. The 502 names the cause, "network is unreachable", where a socket error used to come back.
• The base now runs a third user. The tests' "who runs what" check expects agentenv-egress, running the proxy alone.

Testing

On an EC2 x86_64 host with local sandboxes:

Test	What it shows	Result
Go, in the image build and the egress job	The pages the follower's writer wrote (testdata/) read as the universe they hold; a page reader that rejects a torn page; the universe left held for 30 s; ClientHellos read across records, and their SNI and ALPN, and one whose fields overrun it refused; resumption extensions left out upstream; 22 non-global addresses refused; and, against TLS servers in the process, a site passed through on real time and inside its certificate, intercepted over h2 outside it, an unverified site refused by the client, plain HTTP forwarded, and boot minting the CA once with its key private. After review: every address tried in turn, each by its own probe, one already found working first, one that stops answering giving way to the next, and a new one judged by its own probe; the verified chain's shared dates bounding pass-through; a site asking for a client certificate passed through; an upgrade relayed both ways over plain HTTP; a 100 Continue upload answered at once; the caches bounded; no site held up by another's slow probe; a panicking probe leaving no one waiting; an app's store that can't take the CA warned of while the boot goes on. All under -race	27/27
test_a2a_object_transfers.py (protocol, unit)	A process made direct takes no proxy from the environment for its transfers but still its certificates, and both computer servers make themselves direct as they start	2 new
test_computer_egress_base.py (new, unit)	The proxy's CA window is routed sites'; root's supervisord runs it as its own user; init boots it first; the session's settings match a login shell's and the local provider's trust variables, and name the address the proxy listens on; the pages the Go tests read are what clockpage.encode writes	5/5
egress_test.py (new)	The session user can't read the CA's key, stop the proxy, replace it, or add to its roots or the trust files, and a killed proxy is back within 3 s. All 22 private and local destinations are refused and logged. With the universe 182 days back, Java's HttpClient, an official Node 24 build's fetch and curl reach example.com through it (Java and Node refuse it without the proxy). Fresh handshakes through 12 jumps of +1 week with the universe a month on: none aborted, intercepting along the way	4/4
base_computer_test.py, computer_env_test.py, computer_clock_test.py, clock_desktop_test.py, ca_trust_test.py	Regression, with every session program now going through the proxy: who runs what, the probe at full, recordings, a closed network, the clock through jumps, a fresh Chrome on a routed site, the CA trust of Node and both JDKs	23/23

The clock helpers these tests share (UniverseClock, computer_container, session_run) moved into the computer tests' conftest. CI's slow tier ran them at f337d4a: egress_test.py 4/4, clock_desktop_test.py 3/3, computer_clock_test.py 1/1.

Measured on the host, through the clock desktop's curl and Chromium. "Passed through" is the clock armed at now; "intercepted" is the universe 182 days back:

Check	Passed through	Intercepted
JA4 at tls.peet.ws, curl	t13d3112h2_e8f1e7e78f70_b26ce05bbdd6	the same
JA4 at tls.peet.ws, Chromium	t13d1518h2_8daaf6152771_4980c97edce0	the same
24 bot-protected sites, page loaded with no challenge (headless Chromium)	11	12 (23 of 24 sites gave the same result both ways)
Debian 13.7.0 netinst ISO, 792,723,456 bytes, sha256	intact, 7.2 s	intact, 6.6 s

On Modal (modal_vm), at ab865c9: the bundle registered into throwaway S3 and ECR stores, composed and probed on a Modal VM, and deployed in a multi env on modal_vm:

Check	Result
Who runs what	root, agentenv-clock, agentenv-egress, the session user
Boot	the CA minted and trusted in agent-env's trust files, the driver venv's certifi bundles and NSS, in 0.75 s, no warnings
A live site from the session, the clock armed 182 days back	example.com 200, intercepted (outside its certificate)
A file loaded by its S3 read grant, and a snapshot uploaded by its write grant	both through, straight to S3: the proxy's log has no S3 row, and no inline fallback was taken
Teardown	clean

Docs

The computers page should say that the ubuntu-24.04 base goes out through an egress proxy on real time, so live sites load at any universe date. It should also cover which clients follow the proxy's settings and which don't.

🤖 Generated with Claude Code

Confidence Score: 5/5

The changes since the previous review appear safe to merge, and both numbered findings are addressed.

Summary

Adds a real-time egress proxy to the ubuntu-24.04 computer so supported clients can reach live HTTPS sites while using universe time.

• Live sites load through the computer even when its universe clock shifts.
• Computer servers send their own object-store transfers directly.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Session client] --> B[Egress proxy on real time]
  B --> C{Destination allowed?}
  C -->|No| D[Refuse connection]
  C -->|Yes| E{TLS needs interception?}
  E -->|No| F[Relay client bytes unchanged]
  E -->|Yes| G[Check site certificate on real time]
  G --> H[Give client a locally signed certificate]
  H --> I[Relay decrypted traffic over TLS]
  J[Agent-env server transfers] --> K[Object store directly]

Loading

_{Reviews (12) · Last reviewed commit: "fix(computers): the egress job pulls Go ..." · Reviewed by Greptile}

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	golang/​github.com/​refraction-networking/​utls@​v1.8.2

View full report

[socket-security]

Warning

Review the following alerts detected in dependencies.

According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.

Priority	Alert  (click "▶" to expand/collapse)	Action
	High CVE: compress zstd: Panic on two-block frames in golang github.com/klauspost/compress CVE: GHSA-fpmh-frq8-7rj8 compress zstd: Panic on two-block frames (HIGH) Affected versions: < 1.20.2 Patched version: 1.20.2 From: src/agent_env/computers/artifacts/ubuntu-24.04/egress/go.mod → golang/github.com/refraction-networking/utls@v1.8.2 → golang/github.com/klauspost/compress@v1.17.4 ℹ Read more on: This package | This alert | What is a CVE? Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: Remove or replace dependencies that include known high severity CVEs. Consumers can use dependency overrides or npm audit fix --force to remove vulnerable dependencies. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore golang/github.com/klauspost/compress@v1.17.4. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.	Warn
	Potential vulnerability: golang golang.org/x/crypto with risk level "medium" Location: Package overview From: src/agent_env/computers/artifacts/ubuntu-24.04/egress/go.mod → golang/github.com/refraction-networking/utls@v1.8.2 → golang/golang.org/x/crypto@v0.36.0 ℹ Read more on: This package | This alert | Navigating potential vulnerabilities Next steps: Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support@socket.dev. Suggestion: It is advisable to proceed with caution. Engage in a review of the package's security aspects and consider reaching out to the package maintainer for the latest information or patches. Mark the package as acceptable risk. To ignore this alert only in this pull request, reply with the comment @SocketSecurity ignore golang/golang.org/x/crypto@v0.36.0. You can also ignore all packages with @SocketSecurity ignore-all. To ignore an alert for all future pull requests, use Socket's Dashboard to change the triage state of this alert.	Warn

View full report