Enterprise networks.

Everything tebako downloads — runtimes, payloads, registry indexes — uses one in-process HTTPS client. Getting through an enterprise network is always the same two questions:

Both are answered by environment variables or by the network: section of ~/.tebako/config.yaml. Environment always wins, per key. There is no "disable verification" setting and there never will be — a wrong answer fails closed with a named error, never a silent fallback.

The standard spellings work, uppercase or lowercase:

or the same policy in config:

Precedence is HTTPS_PROXY → HTTP_PROXY → ALL_PROXY → network.proxy → direct. HTTPS connections tunnel through the proxy via CONNECT and TLS still terminates at the target host — an inspecting proxy re-encrypts, which is exactly what the trust half below is for.

Proxy authentication uses credentials embedded in the URL (http://user:pass@proxy.corp:3128). Credentials never reach the log: the audit journal records proxy=http://*@proxy.corp:3128. A proxy that rejects them answers with the named ProxyAuthRequired error (HTTP 407). SOCKS proxies are not supported and are refused by name.

1. The default (bundled Mozilla roots). Nothing to configure. Works wherever the proxy passes TLS through untouched.

2. The platform store — for roots your IT pushes by GPO/MDM into the operating system’s own trust store (Windows certificate store, macOS keychain, the Linux CA bundle). One env var:

or in config:

3. Additive PEMs — keep the bundled Mozilla roots AND ALSO trust your organization’s root, from a PEM file:

The additive and platform spellings do not combine — the OS verifier trusts exactly the OS store, so tls_roots: platform together with extra_ca is a named error that tells you to push the CA into the OS store instead. A PEM that is unreadable or does not parse is a named error at startup, never a silently skipped file.

Every process that fetches writes its network policy to the audit journal, ~/.tebako/journal.log:

Fleet tooling can scrape the journal to prove which machines run with which policy.

The settings above govern tebako’s downloads. A packaged application making its own TLS connections (Ruby’s net/http, Python’s requests, …) is a separate surface: it reads the runtime’s usual variables, and a payload image can ship its own CA bundle that the driver exports as SSL_CERT_FILE at boot (a mounted ssl/cert.pem marked for materialization). Your organization’s root can travel inside the payload itself — no host configuration needed. The runtime’s own tooling conventions (REQUESTS_CA_BUNDLE, SSL_CERT_FILE, …) apply unchanged.

For sites with no outbound access at all, pair this guide with Curate a local library: one team mirrors the needed artifacts into a directory registry (file:///), and every machine installs from it. TEBAKO_OFFLINE=1 turns any accidental network reach into a hard error instead of a leak.

The size-gated bootstrap (the first bytes of a standalone packaged executable) deliberately ships without the proxy/additive-CA machinery to stay under its 3 MiB gate. It always honors TEBAKO_TLS_PLATFORM_ROOTS; pointed at a proxy or TEBAKO_EXTRA_CA, it stops with the named NetworkingCompiledOut error instead of guessing. The fix on such machines is the toolchain path — tebako install and the shims — which carries the full surface, or the platform-store spelling, which works everywhere.