Build it yourself.

Repositories.

The source index lives at guardtalk.io/source ↗. Build and install walkthroughs live at docs.guardtalk.io ↗.

What the index carries: the manifest pinning each repository, the device trees for the target codenames, the build scripts, and the on-device asset pack. What it cannot carry yet is a release tag, because no release has been cut.

// confirm §19.6manifest revision and release tag

What to read first, if you are checking rather than building: the manifest, then the delta between the device trees and their upstream equivalents. The removals are the product: the components that are absent are what makes this OS what it is. They are visible as diffs rather than as adjectives.

The base is AOSP, documented at source.android.com ↗. The hardening tradition this build follows is not ours, and the page says whose it is rather than implying it.

Licence obligations for every upstream component are listed on licences, as a page rather than a footnote.

Build targets.

There is one target per device codename. Two are named today: tokay and rango. Which model each codename is, and the rest of the Pixel 8 and Pixel 9 codenames, are unresolved — see target devices.

// confirm §19.4remaining device codenames

A target build does not produce every partition on the device. Stating which is which matters more than the count.

• Built from the GuardTalkOS OUT tree — system, system_ext, product, vendor.
• Factory-signed and paired, not rebuilt — bootloader, radio, boot, vendor_boot, dtbo.

The second group is paired with GuardTalkOS, not rebuilt by it. Those partitions carry the vendor's signatures and the vendor's firmware support lifetime. That is a limit, not a preference. The trust chain below the OS is not ours to hold, and verified boot stops at the same line.

The exact membership of each group per release still has to be checked against the build tree before it is published as fact.

// confirm §19.2partition split per release

The OUT tree is the build's output directory. A completed target leaves the images there, along with a great deal that is not a release: intermediates, symbols, test artefacts. The release artefacts are the small subset published alongside SHA256SUMS, and nothing else.

The lunch combination, the target names and the host toolchain requirements ship with the first release. The site is not going to print a command nobody can run.

// confirm §19.6targets, toolchain and host requirements

Sign with your own key.

Generate the AVB key pair yourself. avb_pkmd.bin is the public-key metadata blob the bootloader stores, and it is the entire trust anchor of the device.

The order matters. Sign the images with your key, flash avb_pkmd.bin into the bootloader's custom-key slot, flash the images, then lock the bootloader. Locking last is what makes the anchor binding.

One consequence is worth stating plainly, because it surprises people. If you build and sign your own images, the published SHA256SUMS will not match them. That is correct behaviour, not a failure: our hashes verify our artefact, and your build is verified by your key. Verification and reproduction are different acts, and only the second one is missing here.

Where you keep the private key is the security of the whole scheme. It is not escrowed here and it cannot be recovered here. Lose it and you cannot sign an update your locked bootloader will accept. That is the cost of holding the anchor yourself, and it is the correct cost.

The workflow is alpha, and the enforcement state per release has not been confirmed. The step-by-step form of it, with the boot-time check, is on the AVB key step.

Reproducible builds.

What reproducible will mean here. Given a published build environment and a documented procedure, an independent builder reaches the published digests. The source is taken at the release tag. Byte-identical, not equivalent, not close.

How it will be checked. Four parts, none of which exists yet.

• A pinned build environment published by digest, so that "the same toolchain" is a statement someone can check rather than accept.
• A rebuild procedure in the documentation, written so a third party can follow it without asking us anything.
• A byte-level comparison of the rebuilt artefacts against the published ones, with every difference enumerated when there are any.
• Third-party rebuild results recorded against the release they tested, including the ones that failed.

What stands in the way. Build timestamps, absolute build paths, signing material and any vendor step that is not deterministic. Each has to be removed or accounted for, and none of that work is done.

That is why this is planned with no date attached.

// confirm §19.2reproducible-build target

What building yourself does not change.

Holding the anchor is a real change in who you have to trust. It is not a change in what the OS is for, and the honest list is short.

• The threat model does not move. A self-built image removes vendor trust from the artefact, not the network from the adversary. See the threat model.
• The Gateway is still required. Built, signed and locked by you, GuardTalkOS is still a stripped ROM without the checkpoint it was designed around. See the Gateway ↗.
• The remaining surfaces stay real. The Wi-Fi stack, the Messenger and the launcher are still there, and a well-resourced 0-day still has somewhere to land.
• Alpha still means alpha. Building from source does not advance the on-device validation that your device depends on. See the status board.

Contribution and disclosure.

Each repository states its own branch model and licence; the index at guardtalk.io/source ↗ is the entry point.

// confirm §19.15contribution process and branch model

Report a security issue, or a build that does not match its published hash, through the disclosure address at guardtalk.io/security ↗. A mismatch is a security report, not a support ticket.

We hold no external review of this build and we do not claim one. On-device validation is under active bisect, and the status board carries the dated version of that sentence. No bounty is offered; saying so is more useful than leaving it implied.

What is not true yet.

Everything above that is not shipped, gathered in one place so that no reader has to assemble it from qualifiers.

• No release is published, so there is no tag, no manifest revision and no artefact list. // confirm §19.6
• No reproducible-build target. // confirm §19.2
• No published toolchain or host requirements. // confirm §19.6
• No committed update cadence. // confirm §19.4
• No support-lifetime statement for any target device. // confirm §19.4