security / current release boundary
Checksummed and signed, with an explicit bootstrap boundary.
WaitDojo v0.2.4 embeds an Ed25519 verification key and rejects an update archive whose signature does not verify. Its Unix updater cannot finish replacing the running binary. Users on v0.2.3 and v0.2.4 need one public-installer bootstrap to v0.2.6; signed in-product updates work from v0.2.6 onward. This also does not retroactively authenticate the v0.2.3-to-v0.2.4 update or a fresh shell install.
What published v0.2.6 verifies now.
- The installer downloads the selected release archive and its exact .sha256 file.
- It validates the checksum-file shape, computes SHA-256 locally, and stops before installation when the values differ.
- It checks that the archive contains an executable WaitDojo binary with Codex and Claude Code command support.
- The installer source and aggregate SHA256SUMS file are publicly reviewable.
- Each archive has a detached Ed25519 signature. v0.2.4 carries the trusted key and verifies an update archive before extraction, but its Unix updater cannot complete the replacement. After a one-time public-installer bootstrap to v0.2.6, later signed in-product updates stop on any signature mismatch.
- The separately signed release-provenance document binds all four archive digests and its release signing public key to the tag commit, tag ref, source repository, and release workflow.
Independent verification and its boundary.
v0.2.4 is the cryptographic bootstrap release: it carries the trusted public key and verifier, while v0.2.3 does not, so the v0.2.3-to-v0.2.4 update remains checksum-only. It is not the functional self-update bootstrap: v0.2.4 retains a Unix replacement-handle bug and cannot repair itself. Users on v0.2.3 or v0.2.4 need to run the public installer once to reach v0.2.6; signed in-product updates work from v0.2.6 onward.
The shell installer still begins from code, an archive, and a checksum served by this site. A fresh install does not independently authenticate the key it is receiving. Review the installer and verify the archive signature and signed provenance against a public key obtained through a trusted channel before treating a fresh install as publisher-authenticated.
Rotation and incident response are fail-closed.
A repository Actions secret holds the Ed25519 signing key because this private repository is on GitHub Free. Publication is owner-authorized; this GitHub plan does not enforce a protected-environment approval. The workflow derives and compares the public key, verifies every archive and provenance signature, and refuses the site handoff on any missing or invalid trust artifact.
Planned key rotation uses an old-key-signed bridge release that embeds the new public key. Published tags and signatures are never overwritten. If the old key is suspected or confirmed compromised, it cannot securely authorize that bridge: automatic updates stop, the compromised key is removed from CI trust, and users must obtain and verify the replacement key through an out-of-band trusted channel before a manual reinstall or recovery bootstrap.
Review before installing.
Terminal — bash
A dry run shows the runtime, archive, source URL, and actions without changing files. For privacy boundaries, see privacy; for local diagnostics, see the doctor guide.
Report a security concern.
Contact Nishant Bhargava directly. Do not include production prompts, repository contents, credentials, tokens, or private coding-agent output. Include the affected version, archive name, expected and observed digest, and a minimal reproduction.