Enterprise networks.

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

Both questions are answered by environment variables or by the network: section of ~/.tebako/config.yaml. The 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 requires configuration, and the spelling works wherever the proxy passes TLS through untouched.

2. The platform store — for roots the organization’s IT department pushes by Group Policy Object (GPO) / mobile device management (MDM) into the operating system’s own trust store (Windows certificate store, macOS keychain, the Linux CA bundle). One environment variable arms it:

or in config:

3. Additive PEMs — the bundled Mozilla roots are kept, and the organization’s root is additionally trusted from a Privacy-Enhanced Mail (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 directs the operator 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, and similar clients) 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). The 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, and similar variables) apply unchanged.

For sites with no outbound access at all, this guide pairs 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.