What ships in v1
This page is the honest scope of qdistro v1: what the release includes, what ships behind an experimental label, and what is planned for a later version. It mirrors the project’s internal release-scope table, including the places where the documentation once promised more than the code delivers — those are listed as planned, not quietly shipped.
A note on dates: v1 is pre-release. Everything under In v1 is implemented and is going through the release test battery; this page describes the v1 scope, not a shipped-and-signed build. When a signed release manifest exists, the signature-verified install flow is the trust anchor.
In v1
Implemented, in scope, and going through the release verification passes.
| Capability | What it is |
|---|---|
| Tier 0–3 isolation | Direct, SELinux-confined, rootless-podman, and different-uid waypipe app isolation. Tier-1/2 spawn authorization moves out of shadow mode for the release. (The gVisor paravirt rung, tier 3s, is Experimental below.) |
| qdwin compositor | The libweston + Wayland compositor, with the §4b capture-global gate (screen-capture is shell-only, hidden from ordinary clients). |
| Session stack | qdshell, qdgreeter, and qdlocker — login on tty3, dynamic sessions on tty5+. There is no tty4 LXQt escape hatch. |
| Broker | CheckPermission / RequestPermission, rules + hooks, and an append-only audit trail. RequestPermission enqueues; granting happens through the admin approval paths installed as an installer-chain step — the graphical approval queue, the qdistro-approvals CLI, and the admin TUI. |
| Sessions / silo lifecycle | Create, start, stop, freeze, and egress changes for per-silo workloads. |
| Password vault | The v1 password master-key vault. (The TPM-sealed v2 path is experimental — see below.) |
| Printing | A host print proxy is installed. There is no isolated CUPS VM: the print-VM image is never built or started. |
| Per-silo VPN | An interim host-netns backend. What it does not protect: 802.11, DHCP, and DNS parsing still run on the host kernel — the network-VM swap-in that closes this is post-v1. |
| Templates | Template directories and an example tier-2 policy file are installed. The gated promotion operator flow (build → probe → validate → promote) is not a shipped UI. |
| Browser bridge + extensions | A frozen v1 operation set — ping and containers.* only — with the Chrome-family and Firefox extensions. How you install them in v1: manually. There is no signed extension channel — the Chrome-family extension is loaded unpacked in developer mode, and the Firefox one is a temporary add-on that has to be re-loaded after every browser restart. See Planned below. |
| Firefox containers | Round-trip container integration, relay, and CLI. |
| Filesystem / rollback | Per-user btrfs subvolumes with Snapper rollback. Not in v1: the scheduled backup service, export UI, and restore pipeline — see Planned below. v1 does not promise automated backup or data-loss protection. |
| First-party apps | qterminator, qnotebook, qfileman, and qdbrowser. |
| SELinux policy | Tier-1 policy modules ship. lineage_enforce defaults false and is not enabled by any installer. The tester image sets SELINUX=permissive. |
| Admin app | The tree has Pending, Cache, Rules, History, Workflows, and Silos tabs. The graphical approval queue installs as an installer-chain step — on the bootstrap and the tester image — alongside the non-graphical qdistro-approvals CLI and admin TUI. There are no snapshots or printers panels. |
| Portal backend | xdg-desktop-portal backend — an unconditional installer-chain step. |
Experimental in v1
Shipped behind an explicit experimental label and validated best-effort — use them, but they carry stated prerequisites and unsupported-failure modes.
| Capability | Why it’s experimental |
|---|---|
| Tier-4/5 VM windows | waypipe-over-vsock VM app windows. Functional, but the cross-domain virtio-gpu story is a post-v1 north star. The tester image ships host launch code only; no guest image. |
| Tier-3s paravirt (gVisor) | The paravirtualized rung: a silo workload runs under the gVisor runsc application kernel (systrap platform) in rootless podman as a dedicated qt3s-<silo> uid — its syscalls are served by the gVisor Sentry, not the host kernel. GUI windows reach the admin desktop over a waypipe byte-stream bridge (no fd passing across the gVisor boundary, software rendering, tagged [3s:<silo>]). Constraints: network=none only, dev profile only, explicit launch with no fallback to tiers 2/3, opt-in install (QDISTRO_TIER3S=1) that is absent from the tester image, and runsc itself is provisioned on demand from a pinned, hash-verified release. No KVM claim — the VM tiers above remain the stronger boundary. |
| Tester disk image (raw.xz) | Dev-profile kiwi OEM raw for USB sticks and VMs. Default password qdistro, sshd off, UEFI-only. Not a signed release. A real-stick hardware run is not yet recorded. See the download page. |
| TPM-sealed vault (v2) | Hardware-sealed master key. Engages only where the TPM path validates on reference hardware; otherwise the vault ships password-only. |
Planned (not in v1)
Explicitly not shipped in v1. These are named here so the scope is honest — none of them are enabled by the release install.
| Capability | Status |
|---|---|
| Recall (capture + timeline) | Cut from v1. Capture and the viewer are disabled and the bridge recall.push op is off; the design is kept for a later version. |
| Phone companion (presence / 2FA) | Cut from v1. Pairing/presence code stays in the tree but is not installed or enabled by the release bootstrap profile. |
| Installable ISO image | Cut from v1. An install ISO is a wipe-the-disk installer and is post-v1. Tester releases are a raw disk image (Experimental above), not an ISO. |
| Scheduled backup / export / restore | Planned, not shipped. The docs once described a backup timer, export UI, and restore pipeline as product behavior — none ship in v1. A signed-manifest source verify/restore primitive exists, but the end-to-end user backup story is later. |
| Signed extension distribution | Planned, not shipped. No AMO-signed xpi, no production CRX signing key, no hosted update.xml, no usable force-install deployment (the policy scripts in the extension repos point at paths nothing populates), and no auto-update or revocation channel. v1 users verify the release manifest themselves, build the extension from the pinned source, and load it by hand — nothing checks the artifact at load time, and a security fix reaches them only when they rebuild and re-load it. |
| Network VM swap-in | Planned. Moves 802.11/DHCP/DNS off the host kernel (see Per-silo VPN above). |
| Workflow engine, cross-machine RDP, scanner, virtual-camera ML, lineage store, manifest registry | Post-v1 north stars, deferred by design. |
See the threat model for what these features do and do not protect against. The hardened release-install flow becomes signature-verified once the v1 key and manifest are published.