Skip to main content
tuturuuu.com/download lists iOS/TestFlight and Android/Google Play early access, plus verified desktop packages from GitHub Releases. Every distribution is beta and may not be production-ready. Mobile users may need an invitation using their Apple or Google account; installing TestFlight alone does not grant access. The page leads with one recommended download for the visitor’s platform, detected from the request user agent (iPadOS desktop agents are corrected on the client), and lists every other platform compactly. Desktop visitors also get a QR code to the same page, which then leads with their phone’s store. A desktop OS without a published package falls back to opening the web app. Versions are never guessed: desktop versions and checksums come from the cached GitHub Releases parse, and mobile store links come from the MOBILE_*_STORE_URL root workspace configs. The mobile version shown is the policy’s MOBILE_*_EFFECTIVE_VERSION, not a store lookup. Only HTTPS apps.apple.com, testflight.apple.com and play.google.com links without credentials or ports are accepted. Play links are rebuilt from the validated package id; while the Android app is in closed testing (ANDROID_PUBLICLY_LISTED in apps/web/src/lib/download-platform.ts), they point at the play.google.com/apps/testing/<package> opt-in page because the public details page returns 404. Without a policy, Android shows that testing link without a version and iOS offers an early-access request. Desktop rows keep the checksum, release notes and Windows SmartScreen note in a collapsed details section. Platform rules are covered by apps/web/src/lib/download-platform.test.ts.

​
Release workflow

.github/workflows/desktop-beta.yaml runs on relevant production pushes or an explicit dispatch from production with dry_run=false. The default manual dispatch is a Windows-only dry run with no publication. Desktop publication is opt-in: keep the repository variable DESKTOP_BETA_ENABLED unset until the selected platforms complete native verification. Windows signing may remain unconfigured under the unsigned-beta policy below. While disabled, the workflow reports coming soon and does not publish; this is a deferred release, not a successful desktop rollout. Set it to true only after completing the platform prerequisites below. Set repository variable DESKTOP_BETA_PLATFORMS to a comma-separated subset of windows,macos,linux (default: all three). Selected platforms build concurrently. To include Windows alongside the existing macOS/Linux channel, set the release variable to windows,macos,linux after this workflow reaches production. A retained macos,linux setting still excludes Windows. Linux and unsigned Windows can ship while another platform completes signing setup. The desktop-beta GitHub environment owns the release configuration. Publication can publish the successfully verified selected-platform subset; failed platforms remain unavailable. Present invalid assets block publication rather than being dropped. Windows packages may be explicitly unsigned under the decision below. macOS still requires its certificate and notarization credentials. Build inputs contain only allowlisted public URLs, publishable Supabase keys, OAuth client IDs, and feature flags. DESKTOP_PUBLIC_CONFIG is a JSON environment variable, validated by scripts/desktop-deployment/public-config.mjs. Never use a general .env file or a Supabase service-role key as a Dart define. The validator rejects unknown fields and elevated JWTs without logging their values. Signing credentials are available only to their OS-specific packaging step, after Flutter compilation. They are never passed into Turbo, Flutter, a source archive, or an artifact path. Windows builds select unsigned packaging only when both direct-signing secrets are absent. Configuring just one secret fails the job. Configured signing failures never retry as unsigned. An explicit vault source requires its Windows token; missing or rejected vault credentials cannot fall back to unsigned packaging. macOS preflight and signature, team, and notarization verification remain strict. The existing verified-platform subset policy can publish successful platforms when another fails. Regression coverage is in desktop-beta-workflow.test.mjs, windows-signing.test.mjs, and verify-publication.test.mjs.

​
Windows signing decision and costs

The 2026-10-22 decision permits UNSIGNED Windows x64 beta installers until trusted signing is available without a new paid account or purchase. This applies to direct GitHub beta downloads, not the Microsoft Store channel. Checksums, bundle auditing, exact-source receipts, and GitHub provenance remain mandatory. No self-signed certificate is presented as trusted publisher signing. Options checked on 2026-10-22:
  • CA-issued Authenticode certificates require a paid certificate subscription. OV/EV pricing and key storage depend on the provider. No certificate was purchased.
  • Azure Artifact Signing, formerly Trusted Signing lists USD 9.99/month for 5,000 signatures and USD 0.005 per additional signature. It requires Azure provisioning and identity validation. No paid account was created.
  • SignPath Foundation is free for qualifying OSS projects. This repository is public and Apache-2.0 licensed, satisfying the public-source/license starting point. Eligibility still requires review of all bundled components, existing releases, an application, a public signing policy, MFA, and assigned author/reviewer/approver roles. Approval and signing credentials are not available, so this is not an immediately usable signing option.
To enable the retained direct Authenticode path later, add both WINDOWS_SIGNING_CERTIFICATE_PFX_B64 and WINDOWS_SIGNING_CERTIFICATE_PASSWORD to the protected desktop-beta environment and leave DESKTOP_SIGNING_SOURCE unset or set to environment. Both the app binaries and completed installer are signed, timestamped, and verified. The PFX path requires a trusted certificate with a private key usable by the existing Windows signer. Hardware-backed or cloud-only CA keys need a compatible signing integration; buying an OV/EV certificate alone does not make it usable as a PFX. For the existing Infrastructure vault path, set DESKTOP_SIGNING_SOURCE=vault and provide DESKTOP_WINDOWS_VAULT_CI_TOKEN after approving the matching Windows signing material in the vault. SignPath or Azure integration requires a separate reviewed change after provisioning; their credentials are not PFX replacements.

​
Signing later

Authenticode needs an OV/EV certificate, compatible hardware/cloud key integration and timestamping. EV does not guarantee SmartScreen reputation. For Azure Trusted Signing (now Artifact Signing), review identity, bounded usage and costs before enabling it. MSIX is separate: reuse desktop-store-draft.yaml and windows-store-manifest.xml, then verify publisher identity, signing, URI activation, upgrades and Store certification. See Microsoft’s signing overview.

​
Install an unsigned Windows beta

The download page includes the x64 installer and installation guidance in English and Vietnamese. Unsigned installers can trigger SmartScreen’s Windows protected your PC warning or show Unknown publisher.
  1. Download the installer only through the official download page or its GitHub release.
  2. Compare Get-FileHash .\Tuturuuu-windows-x64-setup.exe -Algorithm SHA256 with the checksum in the release notes. The notes explicitly identify unsigned builds.
  3. If you trust the release and SmartScreen offers the choice, select More info, then Run anyway. Follow the per-user installer.
Organization policy or Smart App Control may prevent that option. Use the web app instead of disabling Windows protections. A checksum verifies the downloaded bytes; it is not a publisher signature. Unsigned Windows updates require manually running a verified installer. The existing in-app Windows updater still requires valid, matching publisher signatures and rejects unsigned installers.

​
Build Windows artifacts without publishing

Dispatch desktop-beta.yaml on the implementation branch with dry_run=true. The windows-latest job uses placeholder public configuration and contents: read, without signing credentials or publication rights. Dry runs skip release jobs, including on production. Production sign-in and updates need separate qualification. The seven-day desktop-windows-x64-dry-run artifact contains:
  • desktop-artifacts/Tuturuuu-windows-x64-setup.exe: Inno Setup installer.
  • desktop-artifacts/verified-windows.json: installer SHA-256, source SHA, run ID and unsigned-windows status.
  • windows-installed-files.json: installed filenames, sizes/hashes, source SHA, run ID/attempt and installer hash.
The smoke verifies the receipt, required Flutter files and hidden/system files, using literal paths. Reject all reparse points. Root files match the runner/DLL/uninstaller allowlist; data/ permits ICU, AOT and Flutter assets, rejecting .env* path segments, MZ headers and executable/script/debug/credential types. The runner stays hidden until Flutter’s first frame. After 15 seconds the smoke requires a visible main window with the exact title Tuturuuu. Installation and uninstallation each have a 120-second wait, then a 10-second owned-process-tree stop attempt. Uninstall is skipped if the installer is still running; original errors survive cleanup. Inno’s uninstaller exit code signals completion of its actual work; its clone may still finish deleting the original EXE. This proves a first frame, not healthy Firebase, Supabase, caches or widgets: caught startup failures and ErrorWidgets can render. OIDC/runtime variables are removed, but same-user process access is not isolated; a separate smoke job without OIDC is a follow-up. Slow bootstrap leaves the window hidden. A native splash/watchdog is a separate product follow-up; the 15-second gate is unchanged. The production matrix uses the same gate and separate inventory. Fixtures cover hidden files, wrong titles and phase timeouts; the installed-app check is the native gate. See Flutter’s first-frame guidance. Packaging/updating targets x64; ARM64 needs separate native qualification. Keep source signing material in the dedicated encrypted Infrastructure desktop vault. Desktop jobs use protected environment secrets by default; the explicit vault opt-in obtains only the matching platform’s approved material through its separate desktop OIDC contract. Never use the mobile bundle endpoint or token for desktop jobs. Certificate issuance, rotation, and identity verification remain prerequisites for a real release.

​
Packages and trust

  • Windows: per-user Inno Setup x64 installer, unsigned by default when no signing credentials are configured. Configured signing produces timestamped Authenticode signatures. The installer registers and removes the browser-login callback protocol.
  • macOS: universal Apple silicon/Intel DMG. The app and image are Developer ID signed, notarized, stapled, and assessed. Temporary keychain/P12/API-key files are removed in finally cleanup.
  • Linux: Ubuntu 24.04+ amd64 .deb, containing the Flutter runtime dependencies and desktop protocol registration. Install through a package manager so system dependencies are resolved. GitHub provenance and checksums cover the package.
audit-bundle.mjs scans the built app before packaging for credential files, private-key/token markers, service-role JWTs, and links escaping the bundle. This is an additional check, not a substitute for keeping secrets out of builds. Package receipts bind the Windows and macOS verification status to the package hash, source SHA, and workflow run. Publication rejects extra files, missing selected platforms, or mismatched receipts. Actions artifacts expire after seven days and are intended for CI inspection. Public downloads use persistent GitHub Release assets, which do not require a repository token in the browser. The workflow attests the packages and verifies each signed attestation against the exact source SHA, protected production ref, desktop workflow identity, and GitHub-hosted runner policy before it uploads a draft desktop-v<version> prerelease, then makes the complete selected-platform prerelease visible. It never marks the desktop beta as the repository’s latest stable release or overwrites an existing release tag. A failed draft is cleaned up only after verifying run ownership; unclaimed drafts reserve their version for the next derivation to skip; do not replace assets of a published tag. Draft publication resolves the authenticated gh release view database ID and reads the release by REST ID; the release-by-tag endpoint can return 404 for an existing draft. Before making the prerelease visible, the publisher checks the resolved ID, exact expected tag and source SHA, draft/prerelease flags, and the complete owned asset names, upload states, and SHA-256 digests. A lookup or identity mismatch leaves publication blocked. The actual publisher’s mocked-CLI 404 and mismatch regressions run with node --test scripts/desktop-deployment/publish.test.mjs; no release is written by those tests. The download page caches public release metadata for five minutes and sends package downloads directly to GitHub’s CDN. It validates the exact repository, tag format, filenames, uploaded state, positive sizes, and GitHub SHA-256 digests. Each platform uses its latest verified release independently. Unavailable platforms show an honest unavailable state with a web-app alternative; they never produce guessed download URLs.

​
Verification

Local validation stays limited to non-build checks and is admitted through the resource queue:
Run focused Infrastructure route, operator UI and source TypeScript checks when those surfaces change. Do not run bun validate, bun setup, app/package builds, or native release builds locally. Require the applicable app and desktop release builds in CI for the exact source commit. prepare-macos.mjs is runner preparation that rewrites Firebase metadata and copies the selected flavor plist; it is not a read-only verification command. Before publishing, verify installation, browser sign-in callbacks, workspace isolation, resizing, and core app flows on each supported OS. A passing macOS build does not prove Windows/Linux runtime compatibility. Linux CI installs the generated package, waits for a visible first-frame window under Xvfb, and checks that a harmless browser callback activation leaves the app running. This smoke check does not prove authenticated sign-in or interactive Polkit updates. Never label missing platform runtime or signing verification as complete. The separate mobile-build-windows.yaml development check runs Flutter setup without an Actions cache. If its Windows job remains in Post Setup Flutter after the artifact upload, inspect the exact job and rerun that workflow on the same commit. The post-job cache upload is not evidence that the build failed.

​
Automatic desktop updates

Published desktop builds include DESKTOP_RELEASE_RUN_ID, supplied directly by desktop-beta.yaml. Development builds and mobile store builds do not run the desktop updater. Successive betas differ by version (see Versions and release notes); the updater compares versions, and the run ID only orders legacy run-suffixed tags.

​
Versions and release notes

See Desktop Release Versioning for version allocation, the notes template, and failed-draft recovery.

​
Current provisioning prerequisites

See current provisioning prerequisites.

​
Windows Store draft channel

desktop-store-draft.yaml is a manual build. Its default production-only mode produces an unsigned MSIX artifact for the reserved Tuturuuu product (9N7B6VC7RR7W), using the exact Partner Center package name and publisher from windows-store-manifest.xml. Microsoft signs packages distributed through the Store. This job does not upload or submit an app for certification. It signs a separate temporary copy with a runner-local certificate, installs it, verifies the package identity and visible first frame, and exercises a harmless browser callback. The unsigned submission artifact is unchanged; the test package and certificate are removed afterward. WACK runs when the kit and an interactive session are present. A missing kit/session writes an explicit submission-blocked report and fails the submission job, preventing MSIX upload. Only an explicit diagnostic-only run may finish with blocked evidence; it never uploads a submission MSIX. When WACK runs, a failed, missing, or non-passing report fails either mode. Inspect the attached validation reports before submission. The prerequisite policy is covered by store-certification-gate.test.mjs; actual PowerShell execution and WACK remain Windows CI gates, not evidence established by source-policy tests on another OS. For pre-promotion diagnostics, dispatch this workflow on main with diagnostics_only=true. The job uses the separate desktop-diagnostics environment, restricted to the main branch and containing only DESKTOP_PUBLIC_CONFIG. Keep desktop-beta restricted to production; do not copy signing secrets into the diagnostics environment. A branch-policy rejection happens before runner allocation and produces no build or certification logs. It runs the same production-channel build, installed-app smoke, and strict certification checks, but uploads only validation evidence. It never uploads the submission MSIX, submits to Partner Center, or publishes a beta. Main without this explicit input and all other branches are skipped. This permits investigation of certification blockers before production sync; a diagnostics run is not evidence that production or Store distribution changed. Store builds omit DESKTOP_RELEASE_RUN_ID: the Store manages their updates, while the direct EXE installer remains a separate beta channel with optional Authenticode signing. The MSIX package version uses major/minor plus the dedicated workflow run number, with a zero revision required by Store submissions; app display versions remain managed by Release Please. The run number must fit the MSIX 16-bit component. Before submission, validate on Windows with Windows App Certification Kit and verify packaged browser sign-in callbacks, media permissions, file selection, installation, and Store upgrades. Complete truthful listing screenshots, privacy and data declarations, age rating, restricted runFullTrust justification, and reviewer access instructions. The current product is a draft and its Store link must not be advertised as an available download until Microsoft approves it.

​
Linux update trust

Linux beta packages trust the protected GitHub release and its asset digest; they do not carry a separate publisher signature. Compromise of that release authority can compromise an accepted Linux update. Polkit asks for installation consent. The root-owned packaged helper copies the selected archive into a private root-owned staging directory, rechecks its digest and package identity there, and installs it with apt so dependencies are resolved. It never installs the user-writable cache path directly. macOS and the Windows in-app updater additionally require OS publisher signatures. Unsigned Windows betas require manual installer updates.

​
Verify downloaded desktop packages

Every platform package has cryptographically signed GitHub provenance. Verify a package before installing it using GitHub CLI and the exact source SHA recorded in that release’s notes:
Use the downloaded .dmg or .exe path to verify those platforms. The workflow runs the same verification before publication and blocks the whole selected release if any signature, artifact digest, or workflow identity fails. Linux’s signed provenance covers the exact Debian archive; it is not an embedded Debian publisher signature and the current Linux updater does not independently verify provenance. macOS and the Windows in-app updater additionally enforce native publisher trust; unsigned Windows installation is a manual trust decision. Do not describe receipt hashes alone as cryptographic signature verification. Signed Windows direct distribution requires a trusted Authenticode certificate. A Microsoft account or Store registration alone is insufficient. Microsoft Artifact Signing requires an Azure subscription, identity validation, a certificate profile, and a CI workload identity. Its non-exportable key cannot be retrieved as a PFX. The unsigned beta exception above applies until a supported signer is provisioned.

​
Failed platform builds

Platform builds run independently. If one fails, the publication job may still publish the successful platforms after exact run/source/hash receipts and signed provenance verification. A present but incomplete or invalid package blocks publication; missing failed platforms remain unavailable. Cancelled workflows do not publish. The workflow itself remains failed so the platform problem stays visible. macOS signing failures report only a fixed stage name, such as certificate import, artifact signing, notarization, or Gatekeeper assessment. Private command arguments, stdout and stderr remain suppressed. Check the named provider stage without posting credentials or weakening the signing gates.

​
Infrastructure desktop status

The root workspace’s Infrastructure Desktop deployment page shows public production beta workflow jobs and the latest published artifact for each platform. A checksum or release entry is metadata, not independent signature verification. The explicit provenance step is reported only when that step passed in the shown run; artifacts from earlier runs remain separate. Provider configuration stays unknown because private signing credentials are never queried or exposed. Secure management links open the protected GitHub environment, Apple certificates, Microsoft signing resources, and the existing Microsoft Store submission. Windows Store MSIX drafts use the reserved identity and become Microsoft-signed only after certification. They do not make the direct-download EXE signed or available. Regression coverage: Infrastructure desktop status parser and navigation tests.

​
Windows certification diagnostics

A Store draft validation retains the installed executable’s embedded manifest, process/window DPI awareness, and a compact list of non-passing WACK tests in its validation artifact. Missing manifest-tool output is explicitly unavailable. These receipts help distinguish packaging errors from certification-tool warnings; they do not approve a package. The submission gate still requires an overall WACK PASS, plus the existing runtime and publisher review gates. Do not remove Flutter license notices or required plugin functionality merely to hide an informational test. Microsoft documents optional Desktop Bridge tests as informational, but a required DPI warning still needs investigation. The Windows runner manifest declares both the legacy dpiAware value true/pm and modern dpiAwareness value PerMonitorV2. Microsoft documents both manifest declarations: Windows 10 version 1607 and later uses the modern declaration in preference to the legacy one. This preserves PerMonitorV2 while exposing the compatible legacy fallback to older consumers. A diagnostic report can still return overall WARNING: observed optional tests flagged Flutter’s compressed NOTICES.Z and process-launch references in bundled binaries, while the required DPI test could not process the executable despite its extracted PerMonitorV2 manifest and positive installed-process DPI receipt. These are different findings. The dual declaration is a compatibility change, not proof the certification warning is resolved. Require a fresh exact-source Windows build, extracted manifest/runtime DPI checks, and overall WACK PASS before submission. Preserve licenses and legitimate functionality while investigating; do not convert warnings into passing results.

​
Infrastructure desktop signing contract

The separate Infrastructure desktop contract admits only the direct desktop-beta.yaml workflow on production, in the protected desktop-beta environment, with audience tuturuuu-desktop-deployment. Signature, issuer, subject, source SHA, numeric run/attempt, event and GitHub-hosted runner claims are checked before credentials can be considered. Mobile store jobs, main-based diagnostics, pull requests and unexpected reusable workflows are excluded. Windows admits an Authenticode PFX and its password. macOS admits a Developer ID Application P12, its password and signing identity, Apple team, and a separate notarization P8 with App Store Connect key/issuer identifiers. Profile validation rejects missing, duplicate, extra or other-platform resources. Public Flutter configuration is a separate contract and never belongs in a signing bundle. Linux and Store MSIX do not consume this signing bundle. The desktop contract, encrypted storage, operator UI, protected bundle endpoint, and runner hydration are implemented as separate layers. The existing mobile vault is unchanged, and desktop publication remains opt-in. desktopVaultEnabled requires an explicit true; implemented source does not establish provisioning, certificate validity or signed runtime success. desktop-deployment/contract.test.ts and desktop-deployment/oidc.test.ts cover platform isolation and locally signed JWT rejection. Actual protected-workflow OIDC, certificate identity, installation, WACK and update proof remain required.

​
Private desktop vault storage

Desktop signing storage is additive and separate from the mobile vault. Windows and macOS have independent draft versions and exact resource names; Linux and Store MSIX drafts do not receive desktop signing bundles. Ordinary authenticated and anonymous database roles cannot read encrypted resources, data keys or token hashes. Service-only administration requires an explicit actor who belongs to the root workspace and has manage_desktop_deployment_vault permission. Each resource is encrypted with AES-GCM and authenticated against its desktop version, platform and resource name. A replacement cannot transplant ciphertext between platforms or versions. Draft writes increment the revision and invalidate readiness; active resource values and encrypted data-key identity are immutable. Validation and activation use the expected revision. Complete resource names are a structural prerequisite, not proof of a valid signing certificate: the server’s certificate and platform readiness checks must succeed before it records a clean validation result. CI tokens contain only a stored hash and bind to a single platform and version. The verified desktop OIDC run and attempt reserve a unique fetch lease before decryption. Completion rechecks current admission, token expiry and revocation, and the active version before any bundle may be returned. A delivered or failed lease cannot replay; a lost response requires a new workflow run attempt. Audit records use fixed event names and contain no credential values or exception text. Both platform environments start disabled. Activating a ready version selects immutable signing material; it does not enable delivery. The operator screen, protected bundle endpoint and optional runner hydration are implemented in the sections below. Environment-secret signing remains the default until DESKTOP_SIGNING_SOURCE=vault is explicitly selected and the independent server admission gates are enabled. None of these source layers establishes certificate trust, artifact signing, notarization or installation proof. Regression coverage: desktop-deployment-vault.sql tests permission boundaries, platform separation, revision invalidation, immutable active bytes, replay and revocation; vault-crypto.test.ts tests tamper and identity binding.

​
Portable certificate readiness

Desktop vault readiness inspects the uploaded PKCS#12 material for one matching private key and certificate, a current validity interval and an explicit code-signing extended key usage. macOS additionally requires the Developer ID Application extension, an exact configured common-name signing identity and a matching team identifier. The notarization key must parse as a PKCS#8 EC P-256 private key. Rejections return fixed codes; passwords, private key bytes and parser errors are never part of a readiness response. Successful responses contain only a certificate fingerprint, expiry and algorithm. These are portable material checks, not operating-system trust-chain or revocation verification, Apple account access, notarization or artifact-signing proof. The protected per-platform signing and verification workflow remains required before publishing a downloadable artifact. The current PKCS#12 parser supports RSA certificate bags; unsupported key/certificate material fails closed instead of being described as ready. Forge documents its PKCS#12 parser and unsupported-key behavior, and Apple documents the Developer ID Application certificate extension. Regression coverage: certificate-readiness.test.ts uses freshly generated synthetic material for key mismatch, missing keys, duplicate matches, validity, code-signing, Developer ID identity/team and notarization-key boundaries.

​
Private desktop administration API

Infrastructure’s desktop administration API requires an authenticated registered satellite actor, explicit root workspace MEMBER membership and the dedicated manage_desktop_deployment_vault permission. Browser mutations additionally require the exact local origin and desktop action header. JSON and multipart uploads enforce actual streamed byte limits, including chunked uploads. Responses expose version/revision/readiness metadata, configured resource names and token identifiers only. Password suffixes, encrypted resources, data keys, plaintext hashes and token hashes are excluded. A newly issued token is returned once to its authorized creator and is never included in state reads. Draft edits use expected revisions and invalidate readiness. Activation repeats time-sensitive portable certificate checks before the atomic revision-fenced activation RPC. Windows and macOS resource names cannot cross platforms. No version operation enables a platform environment. Bundle delivery is independently default-off; the operator UI and protected workflow hydration are implemented separately. These endpoints alone do not establish signed delivery. Regression coverage: desktop access.test.ts, request.test.ts, store.test.ts and mutations.test.ts.

​
Private desktop operator panel

Root workspace members can continue viewing public desktop deployment metadata. Only the verified Infrastructure satellite actor with explicit MEMBER membership and desktop vault permission sees signing administration. The desktop page uses that actor for permission checks; personal and non-root redirects are preserved. Windows and macOS drafts use empty replacement inputs and configured-name status without saved-value readback. Activation requires current revision readiness and still repeats certificate checks on the server. Operators can explicitly change platform admission with the audited controls described below; the UI never changes the global delivery gate. Newly issued seven-day tokens are masked, shown once, discarded on dismissal or actor/page lifetime changes, and cannot be recovered from state. A definitive permission denial hides retained metadata; revision conflicts reload current state while retaining the operator’s replacement input for retry. The client uses shared Internal API functions and actor-scoped TanStack Query keys. This administration surface does not establish provider provisioning, OS trust, WACK, signing, notarization or protected hydration success. Regression coverage: page-access.test.ts and desktop-vault-client.test.tsx. Private operator writes pass no credential variables into the shared TanStack mutation cache and return no signing token as mutation data. The actor-local operation publishes safe metadata and the one-time token separately; completion and unmount clear the operation reference, and cache errors retain only a fixed status/message. Cache regressions cover pending scalar/file writes, dismissal, conflicts, logout and delayed old-actor completion.

​
Protected desktop signing bundle

Infrastructure exposes a separate machine-only POST /api/v1/desktop-deployment/bundle for Windows and macOS. DESKTOP_DEPLOYMENT_VAULT_ENABLED defaults off and the private platform environment must independently be enabled. Operator activation selects an immutable version; it never changes either admission switch. Metadata distinguishes the global switch from platform admission as two independent badges on each platform, including when only one is enabled, without exposing an enabling control. The operator regression covers all four switch combinations. JSON requests may include media-type parameters such as application/json; charset=utf-8; unrelated media types are rejected before verification or service access. The endpoint verifies the signed fixed desktop GitHub OIDC contract before token lookup or service-client access. A hashed token binds platform and active version; the private reserve RPC binds the verified run, attempt and source SHA. Exact resource names, encrypted identities, fresh portable certificate/P8 readiness and a final live revocation/expiry/version check precede response. Failed or delivered leases cannot be reused, including after a response is lost; a new workflow attempt is required. Signing buffers are wiped on success and failure. This endpoint supplies the optional runner hydrator described below. It does not enable any environment, provision credentials, establish OS trust or prove artifact signing/notarization. Linux and Store MSIX diagnostics do not fetch this bundle. Mobile trust remains independent. Regression coverage lives in the desktop bundle-store.test.ts, bundle route tests and operator admission-badge cases; previous actual lease SQL and signed OIDC tests remain the storage and signature boundaries.

​
Infrastructure vault runner opt-in

Desktop beta signing uses the existing environment secrets by default. An operator can explicitly select DESKTOP_SIGNING_SOURCE=vault as a repository variable and configure separate DESKTOP_WINDOWS_VAULT_CI_TOKEN and DESKTOP_MACOS_VAULT_CI_TOKEN environment secrets. This selects the protected Infrastructure bundle endpoint only for the matching production desktop-beta job after Flutter compilation. It does not enable the server vault or either platform; all existing server admission gates still apply. A rejected or unavailable bundle blocks that platform without falling back to legacy credentials. Linux packaging and Store MSIX diagnostics never request this bundle. The runner imports the same pure signing profile allowlist as Infrastructure, checks schema, platform, resource names, canonical base64, SHA-256 and byte bounds, and passes only matching material to a short-lived signing child. No credential is written to GITHUB_ENV, outputs, public build configuration, or artifact paths. Wire-valid resources must also fit a conservative 30,000-byte whole-child environment budget; oversized certificates/scalars block before signing rather than claiming the 2 MiB storage limit is an OS environment guarantee. Private signer files use a separate owned directory (0700 on macOS; inherited ACLs removed and runner-principal access granted on Windows) while public artifact paths remain unchanged. Normal completion and failures remove that directory. Cancellation force-stops only the still-owned signing process tree before cleanup; POSIX uses one immediate process-group kill, avoiding a delayed kill after the parent exits. JavaScript strings and abrupt runner termination cannot promise memory erasure; the hosted runner lifecycle remains the final boundary. Child output is suppressed and only fixed failure messages are emitted. Bundle requests are not retried because lease consumption deliberately binds one run attempt. Regression coverage: scripts/desktop-deployment/vault-hydrator.test.mjs verifies exact projection/hash/stream bounds, protected runner admission, fixed destination, secret-free child environment, private-directory cleanup and post-compile opt-in. These tests do not prove Windows ACL behavior, real GitHub OIDC, signing trust, notarization, or protected production configuration. The workflow’s actual Node 24 and operating-system jobs remain required delivery evidence. See the Node TypeScript runtime and Windows ACL command contract.

​
Audited platform admission control

The Infrastructure desktop administration API accepts enable_delivery and disable_delivery for Windows and macOS. Both require same-origin operator mutation admission, explicit root MEMBER membership, the desktop vault permission, and the current environmentRevision. Enabling also names the active version and its validated revision; the server decrypts and verifies the exact profile, fresh certificate validity, and macOS P8 material before issuing its short-lived internal receipt. Browser credentials or readiness receipts cannot authorize enabling. Disabling needs no credential inspection, so unavailable or expired material does not prevent an operator from stopping delivery. Version activation still does not enable a platform. No operation changes DESKTOP_DEPLOYMENT_VAULT_ENABLED, which remains an independent global default-off gate. Each successful platform control writes an actor audit event and advances the environment revision. Bundle reservation captures that revision; final delivery rejects older reservations after disable, re-enable, or active-version changes. Pre-migration leases with revision -1 cannot deliver. The existing token, environment, then lease lock order remains intact. During additive-schema rollout, metadata reports a missing revision as null; clients must reload a real revision before offering a control. Source availability does not establish activation, OS trust, signing, provisioning, or publication proof. Server-page fixtures mock the current getDesktopPageAccess boundary and return its admitted actor and management permission. Do not mock a superseded root guard or suppress server-only globally to make page tests import. page.test.tsx covers access-before-metadata ordering and member-versus-manager controls; page-access.test.ts independently covers the real satellite actor, root membership and permission checks. Regression coverage: desktop-deployment-admission.sql exercises permission, CAS, freshness, disable/re-enable and legacy-lease denial; admission.test.ts and request.test.ts cover credential-free disable, trusted receipts, fresh material, sanitized failures, and strict browser inputs. The operator panel offers a confirmation before enabling platform admission. It requires the environment’s real revision and matching validated active version; missing rollout metadata, stale actor refreshes, or an in-flight mutation disable controls. Disable remains available without active credentials and while the global gate is off. Both controls use the actor-local mutation boundary, reload on revision conflicts, and discard late results after actor changes. A changed environment revision or active version dismisses an old confirmation. The independent gate badges remain visible for all four global/platform combinations. desktop-vault-client.test.tsx exercises real QueryClient confirmation, CAS, credential-free disable, concurrent dispatch, and actor-ABA publication.

​
Private macOS signing failure diagnostics

The signer temporarily appends its owned keychain to the user search list after capturing the exact prior list. An explicit codesign --keychain still needs the search list for certificate-chain lookup. Registration is verified before signing; the original list is restored and verified before the owned keychain is deleted. An uncertain registration is also restored, and restoration failure blocks success. No default keychain or foreign keychain is changed. Synthetic command tests prove this lifecycle; a real protected signing run must still prove private-key usability, notarization, and release publication. Preexisting files or symlinks at signing paths block preparation. P12 and P8 files are created exclusively; only acknowledged keychain creation permits deletion. Unknown creation ownership is retained rather than guessed. Private-file cleanup errors are redacted and block success. The macOS signer captures child output privately. Failed codesign commands publish only an allowlisted category, artifact kind and bounded numeric exit status, alongside the fixed signing stage. Categories cover keychain access, identity availability, certificate trust, unsigned components, bundle format, resource metadata and timestamp availability; unmatched output is unknown. Paths, signing identities, command arguments, raw output and private inputs never become public error details. This classification preserves failure, cleanup, strict signature/team verification and required notarization gates. It improves next-run diagnosis without establishing or repairing the original signing cause. Regression coverage includes real failing child processes, private-output suppression and failure cleanup in sign-macos.test.mjs, plus the finite classification contract in codesign-diagnostic.test.mjs.