Release Security Status

This page distinguishes implemented security mechanisms from a completed real-world release. Code, tests, or CI gates do not establish the existence of a production signing certificate, accepted notarization record, or trusted public download.

Implemented but inactive release boundaries

The update client accepts only an allowed stable channel, approved HTTPS hosts, and signed data verified with the embedded Ed25519 public key.
Update metadata uses RFC 8785 canonicalization and detached JWS. The client verifies the latest pointer, Release Manifest, platform and architecture, file size, and SHA-256.
The client retains accepted sequence and release identity, failing closed on sequence rollback, different content at the same sequence, or a changed rollout seed for one release.
The release-candidate workflow makes macOS Developer ID signing, Apple notarization, stapling, Gatekeeper verification, and installer-content review mandatory gates.

Default release-trust configuration in the current source is disabled and contains no public host or production key. The repository also contains no real Developer ID certificate, Apple notarization credential, or accepted notarization record. These mechanisms are therefore a candidate-release contract, not a claim that secure updates are available.

Release and update boundaries

A signed update cannot establish the origin of an untrusted first installer. Initial installation still requires a real publisher, official domain, signing identity, and verifiable file hash.
Privacy, EULA, support, and security URLs in a Release Manifest must resolve to real HTTPS texts. Example domains, preview pages, and empty contacts must not be used to generate a release Manifest.
There is currently no automatic rollback service. A successful download does not establish compatibility with old data; compatibility requires evidence for the specific version.
Until the public channel is enabled, update controls must remain disabled and must not poll any preview update source periodically.

See the Upgrade Guide for safer user steps and Platforms and Build Status for the current platform scope.

Security-reporting status

There is currently no published and verified security email, encrypted reporting channel, Vulnerability Disclosure Policy, or response-time commitment. Do not send exploitable details, real credentials, other people's data, or unreleased project content to a public discussion. A normal repository issue must not be assumed to be an official security channel.

If you suspect a compromised credential or device, first stop the affected agents, Automations, Skills, and MCP Servers; revoke third-party Tokens; and retain a redacted timeline and minimal reproduction. Public downloads must remain closed until a real security channel and handling process have passed delivery exercises.