Source release
Let's Infer core source releases are built from an explicit public allowlist. The independently released macOS application is not a core archive or install input. Local agent policy, handoff state, context, scratchpads, credentials, evidence, caches, nested Git metadata, and generated output are never publication inputs.
Build twice and require byte equality:
bin/letsinfer-source-archive build --source . --output /tmp/letsinfer-a.tar.gz
bin/letsinfer-source-archive build --source . --output /tmp/letsinfer-b.tar.gz
cmp /tmp/letsinfer-a.tar.gz /tmp/letsinfer-b.tar.gz
bin/letsinfer-source-archive verify /tmp/letsinfer-a.tar.gzEach archive has one letsinfer/ root and an embedded SOURCE-MANIFEST.json. The manifest records every file's normalized mode, byte length, and SHA-256. The verifier rejects duplicate or unsafe paths, links, special members, metadata drift, unmanifested files, missing files, and content mismatches.
Before publication, scan the complete working tree and the unpacked public tree for every retired namespace or prohibited release term. Repeat --forbid for each term; the tool reports only term hashes so release logs do not reintroduce retired names:
bin/letsinfer-release-audit --forbid RETIRED_TERM . --json
bin/letsinfer-release-audit --forbid RETIRED_TERM /tmp/unpacked/letsinfer --jsonCreate the public repository from the verified unpacked tree. Initialize it as a new repository and make its first commit there; never push or graft the private experimental repository's history. Publication additionally requires the normal test, license/privacy, runtime OCI, signed-catalog, and portable evidence gates.
Automated core releases
Core releases use the protected release branch as their publication boundary. A pull request targeting release runs the complete core tests, builds and tests Watchdog, and verifies two byte-identical public archives. A merge to release repeats those gates and then:
- reads
PRODUCT_VERSIONand refuses an existingvVERSIONtag; - builds the public archive twice and requires byte equality;
- signs the four platform archives' canonical
SHA256SUMSas an SSHSIG with the protected Ed25519 release key; - verifies the signing key against
core/trust/release-public-key.pem; - installs the signed local assets into a temporary prefix;
- creates provenance attestations and an immutable GitHub Release; and
- downloads every published asset, verifies exact bytes, signature and attestation, and performs a second clean-prefix installation.
The publish job is bound to the protected production-release GitHub environment. Store the base64-encoded PKCS#8 Ed25519 private key there as LETSINFER_RELEASE_SIGNING_KEY_B64. The workflow never prints or publishes the private key, and publication fails if its public half differs from the committed trust root.
Versions containing -rc. become GitHub prereleases. Other versions become the latest stable release. Every release contains exactly:
letsinfer-linux-x86_64.tar.gz
letsinfer-linux-arm64.tar.gz
letsinfer-macos-x86_64.tar.gz
letsinfer-macos-arm64.tar.gz
SHA256SUMS
SHA256SUMS.sig
install.shInstall the latest published release through the website's reviewed bootstrap. Until a stable release exists, this resolves the newest release candidate; a stable release takes precedence over a candidate at the same version. The bootstrap then fetches signed immutable GitHub Release assets:
curl -fsSL https://letsinfer.ai/install.sh | shTo pin a specific release or release candidate, pass its explicit published version (replace X.Y.Z below):
curl -fsSL https://letsinfer.ai/install.sh \
| sh -s -- --version X.Y.Zinstall.sh supports Linux and macOS on x86_64 and arm64. Immutable core files live under $LETSINFER_HOME/core; the default creates /usr/local/bin launchers and runs the private core-setup initializer. --user, --prefix, and --no-setup provide explicit alternatives. --no-progress lets letsinfer update own its three-stage TTY display; a direct curl install retains the single percentage indicator. The website build emits the reviewed core installer byte for byte rather than maintaining another implementation.
The macOS application has separate version/build metadata, a protected macos-release branch, namespaced tags, signing, notarization, and release assets. See macOS release.