light-heart-labs--dreamserver/ods/docs/INSTALLER_TRUST.md

Installer Trust And Provenance

ODS installers set up Docker services, write local config, generate secrets, and may install missing prerequisites. Treat them like any other infrastructure installer: inspect the source, pin a release when you want reproducibility, and keep the default localhost security posture unless you intentionally expose services to your LAN.

Install Paths

Public Linux/macOS Bootstrap

The README one-liner downloads this bootstrap script from GitHub:

https://raw.githubusercontent.com/Light-Heart-Labs/ODS/main/ods/get-ods.sh

That script:

• detects Linux, WSL, or macOS;
• installs or checks basic prerequisites where supported;
• clones https://github.com/Light-Heart-Labs/ODS.git with sparse checkout for the ods/ product tree;
• copies the runtime product files into ~/ods;
• runs ./install.sh from that copied runtime tree.

By default the bootstrap follows main. To select a published release tag or another branch, set ODS_REF before running the script:

ODS_REF=main bash get-ods.sh

Manual Source Install

For the most auditable path, clone a known ref yourself and run the installer from the checked-out source:

git clone --depth 1 --branch main https://github.com/Light-Heart-Labs/ODS.git
cd ODS/ods
./install.sh

Use this path when you want to review diffs, pin an exact release tag, or make local modifications before install.

Windows PowerShell Install

Windows users should install from a normal user PowerShell, not an elevated Administrator shell:

git clone --depth 1 --branch main https://github.com/Light-Heart-Labs/ODS.git
cd ODS\ods
Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
.\install.ps1

The PowerShell installer writes runtime state under $env:USERPROFILE\ods by default, or $env:ODS_HOME if set.

Desktop Installer

The Tauri desktop installer is a convenience wrapper around the source installer flow. For maximum provenance control, prefer the manual source install above until you have reviewed the desktop installer build you are using.

Inspect Before Running

If you do not want to pipe a remote script directly into a shell, download and inspect it first:

curl -fsSLO https://raw.githubusercontent.com/Light-Heart-Labs/ODS/main/ods/get-ods.sh
less get-ods.sh
ODS_REF=main bash get-ods.sh

On Windows, clone first and inspect install.ps1 before running it:

git clone --depth 1 --branch main https://github.com/Light-Heart-Labs/ODS.git
cd ODS\ods
notepad .\install.ps1
.\install.ps1

Current Trust Boundary

ODS currently relies on:

• GitHub-hosted source and HTTPS transport;
• release tags or explicit refs for reproducible source selection;
• local generated secrets instead of checked-in default credentials;
• localhost-first service binding by default;
• release validation across zero-prereq distro bootstrap, real hardware installs, product behavior, full-model capabilities, and lifecycle recovery.

ODS does not yet publish a full signed-release or checksum/SBOM chain for every installer artifact. That is the next stronger trust model. Until then, users who need strict provenance should install from a reviewed tag or internal fork and record the exact commit or release tag they deployed.

Provenance Roadmap

The current installer trust model is source-visible and ref-pinnable. The next steps toward a stronger binary and release provenance chain are:

1. Publish checksums for release installer artifacts and document how to verify them before running installers.
2. Sign release artifacts and tags with maintainer-controlled signing keys.
3. Publish SBOMs for release artifacts and core container images.
4. Record build provenance for desktop installer artifacts.
5. Document the exact validation receipt tied to each release candidate.
6. Keep the inspect-first and manual source install paths available even after signed artifacts exist.

These are roadmap items, not current guarantees. Release notes should clearly say which provenance pieces are present for a given release.

Related Validation

• Release Validation explains the User Green gates.
• Validation Matrix summarizes the hardware, distro, capability, and lifecycle evidence.
• Forkability explains how downstream operators can fork, pin, and independently operate ODS.
• Offline And Mirroring covers preserving release refs, images, model artifacts, and validation receipts.
• Security documents localhost defaults, LAN tradeoffs, and disclosure guidance.