tebako v2.8.2: doctor, the corporate-network trust bridge, offline bundles, and per-platform releases

The doctor verb is the first command to run when anything misbehaves:

Every line is a named verdict — ok, note, or problem — and the exit code is 0 for healthy, 1 with a problem count, so it scripts cleanly into CI preflight. tebako doctor --json prints the same report as a machine-readable document. The dispatch section is the shim layer’s own diagnostics rendered in place; the store, network, and trust planes are the CLI’s. The verb is read-only end to end: doctor never repairs; it reports.

The most common enterprise failure used to be a TLS interception wall: the corporate proxy re-signs everything, the payload’s embedded root store does not know the proxy’s CA, and every fetch inside the payload dies with a certificate error. The answer used to be a custom runtime build; it no longer is.

A payload can now declare network: tls_roots: platform (or the user sets TEBAKO_TLS_PLATFORM_ROOTS=1), and the runtime driver merges the image’s bundled roots with the operating system’s own trust store — Keychain on macOS, the Windows certificate store, the system bundle on Linux — into one verified bundle, exported to the interpreter the way its TLS stack expects it. Ruby’s openssl honors SSL_CERT_FILE; the JVM gets the append it understands (-Djavax.net.ssl.trustStoreType=Windows-ROOT on Windows). The merge happens once, at boot, in-process; nothing is fetched, nothing shells out, and the default stays the hermetic image roots — this is opt-in per payload and per machine.

The full recipe is the enterprise networks guide.

Two distribution shapes serve machines that never touch the network, or that should not have to:

tebako bundle assembles a payload’s whole dependency closure — payloads, runtimes, registry registrations, preferences — into one directory, optionally as a tarball. Copy it to the target, install from it, run. It draws from the local store and refuses a partial closure by name, so an incomplete bundle fails on the packager’s desk, not the user’s:

The release page now carries signed system installers — an MSI on Windows and a pkg on macOS — alongside the tarballs and the shell installer. The MSI is Azure Trusted Signing-backed, the pkg is Developer ID-signed and notarized; both install the same four binaries the other channels do.

This change is for payload publishers, and for everyone who has watched a release sit unpublished because one architecture’s build machine failed.

The old pipeline had a rendezvous: every platform leg finished, then a final pass aggregated their artifacts into shared index files and re-uploaded them. Two consequences followed: one broken leg blocked every platform, and the aggregation pass had to mutate published assets — hence the delete-then-replace wedge, in which a re-uploaded name trips the forge’s immutability rules and the release dies at the finish line.

The rendezvous is gone. Each platform leg publishes exactly the assets it owns — the payload, its checksum sidecar, a small manifest shard — each signed in the same invocation, each written once and never mutated. The index consumers need is derived from the release’s own asset listing plus the shards, not stored as a shared file. A broken leg now blocks that leg. The rest of the matrix ships.

The user-visible half is in this release: the shim and bootstrap read the per-platform shards first and fall back to the old monolithic indexes, so older releases keep working untouched. Publishers also gain a loud withdrawal mechanism — a yanked version is marked in the registry and refused by name, instead of vanishing silently.

The full verification story — every release asset is OpenPGP-signed and the CLI verifies them with the embedded tamatebako root key — is in the trust chain post, and the reference pages are up to date: tebako CLI, environment variables, debug & logging.