Releases.

The channel model.

A channel is a named track with its own maturity commitment. Naming three of them costs nothing and tells you which commitments exist. Only one carries builds.

• alpha — live The only channel that produces images. On-device validation runs against these builds and is under active bisect.
• beta — planned Named so the model is legible. It does not exist, and no date is attached to it.
• stable — planned Also named only. A stable channel requires a validation record and an update commitment that GuardTalkOS does not have.

What moves a build between channels is not time. A beta channel needs a validation record that survives without a hold; a stable channel needs that and a committed update path as well. Neither record exists, so neither channel does.

The version string that identifies a build is not published yet.

// confirm §19.6version string and channel naming

A channel name is not a maturity claim. alpha here means what it means in the header pill, in the footer and on the status board. The build runs, the validation does not yet pass without a hold, and no release has been declared finished.

Per-device builds.

Each target device gets its own entry. The fields are fixed, so the shape can be reviewed before there is anything in it. An entry carries the codename, model, build id, version string, date and channel, an excerpt of SHA256SUMS, and the signing key's fingerprint.

The build id and the version string are different facts. The build id identifies the tree a set of images came out of; the version string is what a reader quotes. Publishing one without the other makes a release harder to check and easier to confuse with another.

The signing-key fingerprint sits on clearnet on purpose. It is the one value you need before you go to Tor. Read it from more than one surface before you use it. That workflow is step two of a verification.

The site ships a null release adapter. It reports that no release is published and returns placeholder rows. There is no mock adapter that returns a hash, because a hash nobody can check would break the one thing /verify teaches.

Codenames beyond tokay and rango are unresolved. See target devices for the matrix and for the reason these are targets rather than promises.

Releases onion.

The releases onion carries three things and nothing else: the images, the SHA256SUMS file, and the detached signature over that file. It carries no index page worth reading and no download button, because a download button on a hidden service is still a download button.

The address above is a placeholder, and so is its fingerprint. Both are published with the first release: on this page, on docs.guardtalk.io and on guardtalk.io. Three surfaces, so that one compromised surface is visible rather than authoritative. Read all three before you fetch anything.

Why the images are Tor-only.

Distribution is a security property here, not a delivery preference. Three reasons, each with the part it does not cover.

No clearnet interception of the artefact. An image fetched over the clearnet crosses resolvers, transit networks and whatever terminates TLS in front of the origin. Each of those is a place where a targeted reader can be served a different file from everyone else.

An onion address is derived from the service's public key. Reaching the right address is reaching the right service, because the name and the key are the same fact.

No vendor-CDN dependency. Publishing on a content network makes a third party the custodian of what you receive and of the record of your receiving it. That party can be compelled, breached or simply wrong. A hidden service removes the dependency instead of contracting around it.

No public record of who fetched a hardened build. A clearnet download tells the origin, and anyone watching the origin, that a particular network address collected this OS. For the people this OS is built for, that fact is itself worth collecting.

Now the limits. Tor hides network location from most observers, not from an observer who can correlate both ends of a circuit. Fetching over Tor narrows who can tamper with the artefact; it tells you nothing about whether anyone did. Only the signature and the hash do that, which is why verification is a separate act and a separate page.

And the state is honest: the Tor-only target is planned, and no release is published. Nothing is being distributed today by any route.

Updates.

The update mechanism is not settled. Over-the-air update and a sideload through recovery are different trust models, and the site will not describe one before it exists.

// confirm §19.7OTA versus recovery sideload

Four things hold whichever mechanism is chosen.

• An update is an artefact. It carries a hash and a signature, and the five steps on verify apply to it unchanged.
• A device with a locked bootloader and your own AVB key installed refuses an update image that key did not sign. That mechanism is alpha; its enforcement state per release is unconfirmed. See the AVB key step.
• No cadence is committed. Read the absence of a schedule as an absence, not as a schedule.
• Rollback and downgrade behaviour is unconfirmed. Nothing is claimed about it until it is checked against the build.

What this page does not carry.

• No download control. Not a styling decision. Clearnet carries what you check; the onion carries what you install. Splitting the two is the point, and a button here would quietly rejoin them.
• No release notes and no CVE list, because no release exists. When one does, each entry carries its security patch level and the CVE ids it addresses, in build order.
• No hash. The hash block prints dashes rather than a digest until a human confirms one. On a page whose entire job is checkable values, a plausible-looking hash is worse than a blank.