# Release process (manual, local signing) All TUF signing keys stay on your machine, in `./keystore` (gitignored — never commit it). Nothing here touches CI or GitHub Secrets. ## One-time setup ``` pip install -r requirements-dev.txt python scripts/release/repo_init.py ``` Generates `scripts/release/keystore/` (private + public keys for the root/targets/snapshot/timestamp TUF roles) and `scripts/release/repository/` (initial signed metadata, including `root.json`). **Back up `keystore/` immediately, somewhere private and durable outside this repo.** Losing the root key means you can never publish a trusted update to existing installs again — they'd all need a fresh, non-updating reinstall. Rebuild once more (`pyinstaller labui.spec`) after this step, so the freshly-generated `root.json` gets bundled into the app (see the `.spec` file's `_root_json` check — it only bundles the file if it already exists). ## Every release 1. Bump `__version__` in `core/version.py`. 2. `pyinstaller labui.spec` → produces `dist/LabUI/`. 3. `python scripts/release/repo_release.py` → creates+signs `scripts/release/repository/targets/labui-.tar.gz` and updates the metadata files in `scripts/release/repository/metadata/`. 4. Create (first time) or reuse the GitHub Release tagged **`updates`** on this repo, and upload every file from `scripts/release/repository/metadata/` and `scripts/release/repository/targets/` as release assets, **replacing** any same-named files already there. - This tag is fixed on purpose — the app's `metadata_base_url` always points at `https://github.com///releases/download/updates/`. A normal per-version-tagged release would give every version a different URL, which breaks TUF's requirement that top-level metadata (`timestamp.json`, `snapshot.json`, ...) live at a stable location. - Cut a normal, separately-tagged human-facing release too if you want a changelog/download page — this doesn't have to be the same release. 5. Test: launch a previous installed version, Settings → Check for Updates, confirm it finds and applies the new version. ## Re-signing without a new release Metadata expires even if nothing changed (`expiration_days` in `repo_init.py`: root 365 days, targets/snapshot/timestamp 90 days). If you haven't shipped a release before targets/snapshot/timestamp expire, clients will start rejecting the metadata as stale. Re-sign with: ``` python -m tufup sign snapshot scripts/release/keystore python -m tufup sign timestamp scripts/release/keystore ``` (run from the repo root; adjust the key directory path if you invoke this from elsewhere) and re-upload the resulting files to the `updates` release. Set a calendar reminder — there is no automation for this on purpose (manual signing was a deliberate choice, not an oversight).