feat(native): Linux support, phase 3 — release leg, update channel, download surface

[tlgimenes]

Summary

Phase 3 of Linux support: the AppImage is built, published, and carried by the self-update channel, and Linux browsers get a working download.

Stacked on #5509 (phase 1) and #5532 (phase 2). Based on main so it gets CI — the workflows only run for PRs targeting main, so a branch-based PR gets none. Its diff narrows to phase 3 alone once the parents land; review the phase-3 commits.

Only the update channel is held back on a partial build. A red Linux leg must never freeze the macOS release or the Homebrew cask, which the workflow header designates as the break-glass channel for updater key loss.

Job graph

plan (secretless) → build (matrix, fail-fast: false) → publish (runs even when a leg failed) → promote (the only thing gated on all legs succeeding) → alert (own job, job-level always()).

alert has to be its own job: a step-level condition inside a job that is skipped by an upstream failure never evaluates — always() included — so the most likely new failure mode, a red Linux leg, would otherwise be silent. That is exactly the unbounded-invisible-staleness hazard the alert exists for.

Defects found and fixed in review

An adversarial pass refuted the two headline questions (a Linux failure cannot block macOS distribution; the alert does fire) and found six real defects. Each fix was driven through a stubbed harness, not just read:

• A (tar.gz, .sig) pair could split across runs and be published unverified. An interrupted upload lands the tarball without its signature; a repair rebuilds non-reproducibly, and write-once then keeps the old tarball with the new signature. Every macOS client would fail verification every cycle until a newer version promoted — with CI fully green. promote now verifies every artifact against the pinned pubkey with minisign -V before building the manifest, so signature↔bytes pairing is asserted rather than inferred.
• The pinned AppImage tooling was first exercised on release day — PR CI boot-smoked an AppImage built by rolling tooling, so a bad pin could not go red on the PR that introduced it. Both workflows now seed from one checksummed pin file, and the build is asserted afterwards to have fetched nothing outside it (a CLI bump that outruns the pin table would otherwise download inside the step holding the signing key).
• A missing cask credential had become a silent no-op, freezing the break-glass channel with no signal; it now fails loudly when the App ID is set but the key is not, while staying silent on forks where neither is.
• The static-runtime tripwire could pass vacuously when both probes emitted nothing; the version reached key-holding steps unvalidated; and the alert did not say which leg failed.

Testing

cargo test --workspace 1123 passed / 0 failed; clippy -D warnings, cargo fmt --check, bun run check (which proves pt-br translation completeness), bun run lint, bun test apps/native/scripts (37) all clean. Both workflows parse with every needs: resolving.

Not exercised until a real release runs: the promote job's minisign verification and the two-platform manifest are validated by harness and unit tests, not by an actual tagged release.

🤖 Generated with Claude Code

---

Summary by cubic

Adds Linux desktop distribution and installer: builds and ships an x86_64 AppImage, carries it in the self‑update channel, updates the site to offer a Linux download, and adds a Linux one‑liner installer that verifies downloads. The release pipeline is split so a Linux failure never blocks macOS; assets are verified and AppImage tooling is pinned.

• New Features

  • Linux AppImage: Linux-only Tauri overlay (tauri.linux.conf.json5) builds an AppImage with new icons; boot smoke launches via AppImage AppRun, requests software rendering under Xvfb, and pins @tauri-apps/cli; shared fetch-appimage-tools.sh seeds linuxdeploy and plugins; fetch-rclone.sh adds Linux slugs and a portable sha256 helper.
  • TLS & runtime: opt‑in HTTPS control origin via a WebKitGTK per‑host exception (DECOCMS_LINUX_SECURE_ORIGIN); spawned CLIs get a system+local CA bundle via SSL_CERT_FILE only when a system bundle is found; preview host observer added to stage trust before first load; GUI PATH repair on macOS/Linux; xdg-open browser fallback; apt/dnf ripgrep hints; token namespaces pinned per build profile on every OS (macOS Keychain / Linux Secret Service).
  • Updater: channel serves linux-x86_64; manifest refuses partials and verifies assets with minisign; tarballs are single‑member and name‑pinned; the self‑updater runs only inside an AppImage and applies on quit.
  • Web + install: Linux browsers get a dedicated installer path — install.sh reads the channel’s latest.json, verifies the signed tarball with minisign when available, and falls back to checksum with explicit messaging; the promote job now requires the checksum asset; the download dialog offers the Linux one‑liner and a direct AppImage link pinned by tests; desktop keyring screen names Linux keyrings; menus and empty states offer Linux downloads.

• Refactors, CI & Release Hardening

  • Release: workflow split into plan → build (macOS + Ubuntu) → publish (partial OK) → promote (all legs required, checksums required) → alert (always); macOS release and Homebrew cask never blocked by a red Linux leg; promote verifies each artifact against the pinned pubkey and enforces platform coverage and version pairing.
  • CI: Ubuntu legs for rust checks, Tauri build, and contract suite; required‑check names preserved via matrix aggregators; Linux test stability improvements (process‑group isolation, refuse PGID 0, serialized/chunked runs, capped link parallelism, separate runners, extended budget); script unit tests under apps/native/scripts now run.
  • Tooling pins: shared fetch-appimage-tools.sh is used in PRs and releases; post‑build asserts no unpinned downloads.
  • Dependencies: add and pin webkit2gtk (Linux).

^{Written for commit 9f57188. Summary will update on new commits.}

[cubic-dev-ai]

12 issues found across 51 files

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/native/scripts/boot-smoke-target.ts">

<violation number="1" location="apps/native/scripts/boot-smoke-target.ts:93">
P2: Linux config-only changes can pass against a stale AppImage: `ensureBuilt()` does not treat `tauri.linux.conf.json5` as a bundle input. Include the platform overlay in freshness inputs so `smoke:boot` rebuilds after Linux packaging changes.</violation>
</file>

<file name="apps/native/crates/local-api/src/routes/intercept/sandbox_lifecycle.rs">

<violation number="1" location="apps/native/crates/local-api/src/routes/intercept/sandbox_lifecycle.rs:148">
P1: A newly returned preview URL can load before its GTK TLS exception is installed, so Linux iframe loads can still fail intermittently. Make preview-host registration acknowledge completion before `SANDBOX_START` returns the URL, rather than treating the dispatched callback as already trusted.</violation>
</file>

<file name="apps/native/scripts/fetch-appimage-tools.sh">

<violation number="1" location="apps/native/scripts/fetch-appimage-tools.sh:78">
P1: An added/renamed tool can be downloaded and executed with `TAURI_SIGNING_PRIVATE_KEY` before this check reports it, so the check detects drift but does not prevent the secret-exposure path it is meant to close. Use an unsigned discovery/verification phase before key scope, then run the signed build with network access prevented.</violation>
</file>

<file name="apps/native/scripts/ci/native-update-channel.mjs">

<violation number="1" location="apps/native/scripts/ci/native-update-channel.mjs:159">
P3: An inherited object key such as `toString` is accepted as a platform even though no manifest entry is emitted, violating the documented exact-platform validation. Check own keys so invalid signature maps fail instead of being silently narrowed.</violation>
</file>

<file name="apps/native/src-tauri/src/setup.rs">

<violation number="1" location="apps/native/src-tauri/src/setup.rs:77">
P1: Default Linux launches collapse every sandbox preview onto one `localhost:<preview-port>` origin. Separate sandbox apps can then share browser origin storage/cookies and interact as same-origin frames, defeating the per-sandbox isolation the real-domain origin provides; keep the secure real-domain origin by default or disable/isolate previews in the fallback mode.</violation>

<violation number="2" location="apps/native/src-tauri/src/setup.rs:77">
P2: Linux native dev without the opt-in cannot proxy API requests: local-api now listens over HTTP while Vite still targets `https://127.0.0.1:43121`. Preserve the existing secure origin in dev, or make the Vite proxy target follow the selected scheme.</violation>

<violation number="3" location="apps/native/src-tauri/src/setup.rs:508">
P2: Under `DESKTOP_SELFTEST=1` on Linux, setup runs via `block_on` on the main thread (lib.rs:78). When `DECOCMS_LINUX_SECURE_ORIGIN=1` forces the secure origin (the W1.9 secure-mode Linux self-test), this new `install(...)` call invokes `window.with_webview(...)` and then awaits a oneshot that only resolves once that closure runs on the GTK main thread. Because `block_on` blocks the very thread that must pump the WebKit event loop, the dispatch never executes and the await never returns — the self-test would hang rather than pass. Consider running the Linux secure self-test through the spawned path (as real launches do) or not awaiting a main-thread-dispatched oneshot from the `block_on` path, so the test cannot wedge CI.</violation>
</file>

<file name="apps/native/src-tauri/src/local_tls.rs">

<violation number="1" location="apps/native/src-tauri/src/local_tls.rs:362">
P2: A malformed or truncated configured CA file is treated as a usable system store, so child processes receive a replacement bundle containing only the local CA plus invalid text and lose public TLS trust. Validate that a candidate contains at least one parseable certificate before selecting it; otherwise continue to the next candidate or return `None`.</violation>
</file>

<file name=".github/workflows/release-native.yaml">

<violation number="1" location=".github/workflows/release-native.yaml:487">
P2: A dynamically linked AppImage runtime without `libfuse.so.2` passes this tripwire, so the release can violate its static-runtime requirement and still publish. Treat a dynamic section/`NEEDED` entry as failure, not merely as probe evidence.</violation>

<violation number="2" location=".github/workflows/release-native.yaml:521">
P2: The macOS "Package release assets" step doesn't set `set -euo pipefail`, unlike its Linux twin directly below. Without it, a silent failure in `shasum`/`mv` can stage a stale or empty `zip.sha256` (and continue past a missing file), which the cask step later pins as the Homebrew checksum — breaking `brew install --cask` fleet-wide while the build still looks green. Recommend adding `set -euo pipefail` as the first line of this step's `run:` block, matching the Linux step.</violation>
</file>

<file name=".github/workflows/native.yml">

<violation number="1" location=".github/workflows/native.yml:613">
P2: A cached prior AppImage can satisfy this check when the current build stops producing the expected artifact or changes its name, so the runtime check and smoke can validate old bytes. Clear `target/release/bundle/appimage` before `tauri build`, or assert the newly produced expected filename/mtime.</violation>

<violation number="2" location=".github/workflows/native.yml:623">
P2: A dynamically linked runtime without `libfuse.so.2` passes this gate, so CI does not actually enforce the claimed static-runtime requirement. Require `ldd`'s static/non-dynamic result rather than accepting a readelf dynamic-section result.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: A newly returned preview URL can load before its GTK TLS exception is installed, so Linux iframe loads can still fail intermittently. Make preview-host registration acknowledge completion before SANDBOX_START returns the URL, rather than treating the dispatched callback as already trusted.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/crates/local-api/src/routes/intercept/sandbox_lifecycle.rs, line 148:

<comment>A newly returned preview URL can load before its GTK TLS exception is installed, so Linux iframe loads can still fail intermittently. Make preview-host registration acknowledge completion before `SANDBOX_START` returns the URL, rather than treating the dispatched callback as already trusted.</comment>

<file context>
@@ -108,9 +141,17 @@ fn preview_url(handle: &str) -> Option<String> {
+        // Before the URL escapes: whoever gets it may load it immediately, and
+        // on Linux the host must already be trusted by then.
+        if let Some(observe) = observe {
+            observe(&host);
+        }
+        Some(format!("{scheme}://{host}:{port}/"))
</file context>

[cubic-dev-ai]

P1: An added/renamed tool can be downloaded and executed with TAURI_SIGNING_PRIVATE_KEY before this check reports it, so the check detects drift but does not prevent the secret-exposure path it is meant to close. Use an unsigned discovery/verification phase before key scope, then run the signed build with network access prevented.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/scripts/fetch-appimage-tools.sh, line 78:

<comment>An added/renamed tool can be downloaded and executed with `TAURI_SIGNING_PRIVATE_KEY` before this check reports it, so the check detects drift but does not prevent the secret-exposure path it is meant to close. Use an unsigned discovery/verification phase before key scope, then run the signed build with network access prevented.</comment>

<file context>
@@ -0,0 +1,111 @@
+# to remove. A download can only ADD a name, so an exact set comparison
+# catches that drift, and it turns the bump into a red PR leg instead of a
+# silent release-day fetch.
+if [ "${1:-}" = "--verify-only" ]; then
+  unpinned=""
+  for path in "$TOOLS"/*; do
</file context>

[cubic-dev-ai]

P1: Default Linux launches collapse every sandbox preview onto one localhost:<preview-port> origin. Separate sandbox apps can then share browser origin storage/cookies and interact as same-origin frames, defeating the per-sandbox isolation the real-domain origin provides; keep the secure real-domain origin by default or disable/isolate previews in the fallback mode.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/src-tauri/src/setup.rs, line 77:

<comment>Default Linux launches collapse every sandbox preview onto one `localhost:<preview-port>` origin. Separate sandbox apps can then share browser origin storage/cookies and interact as same-origin frames, defeating the per-sandbox isolation the real-domain origin provides; keep the secure real-domain origin by default or disable/isolate previews in the fallback mode.</comment>

<file context>
@@ -35,6 +35,48 @@ pub enum SetupError {
+    let mut origin = control_origin::current(selftest);
+    #[cfg(target_os = "linux")]
+    {
+        origin.secure = linux_secure_origin_enabled();
+    }
+    origin
</file context>

[cubic-dev-ai]

P2: Linux config-only changes can pass against a stale AppImage: ensureBuilt() does not treat tauri.linux.conf.json5 as a bundle input. Include the platform overlay in freshness inputs so smoke:boot rebuilds after Linux packaging changes.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/scripts/boot-smoke-target.ts, line 93:

<comment>Linux config-only changes can pass against a stale AppImage: `ensureBuilt()` does not treat `tauri.linux.conf.json5` as a bundle input. Include the platform overlay in freshness inputs so `smoke:boot` rebuilds after Linux packaging changes.</comment>

<file context>
@@ -0,0 +1,110 @@
+    return {
+      platform: "linux",
+      bundlesArg: ["--bundles", "appimage"],
+      bundleDir: join(desktopDir, "target", "release", "bundle", "appimage"),
+      isBundleArtifact: (name) => APPIMAGE_ARTIFACT.test(name),
+      launchedBinaryRelPath: join(
</file context>

[cubic-dev-ai]

P2: A cached prior AppImage can satisfy this check when the current build stops producing the expected artifact or changes its name, so the runtime check and smoke can validate old bytes. Clear target/release/bundle/appimage before tauri build, or assert the newly produced expected filename/mtime.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 613:

<comment>A cached prior AppImage can satisfy this check when the current build stops producing the expected artifact or changes its name, so the runtime check and smoke can validate old bytes. Clear `target/release/bundle/appimage` before `tauri build`, or assert the newly produced expected filename/mtime.</comment>

<file context>
@@ -466,17 +575,79 @@ jobs:
+        working-directory: apps/native
+        run: |
+          set -euo pipefail
+          APPIMAGE=$(find target/release/bundle/appimage -maxdepth 1 -name '*.AppImage' -print -quit)
+          if [ -z "$APPIMAGE" ]; then
+            echo "::error::no .AppImage produced under target/release/bundle/appimage"
</file context>

[cubic-dev-ai]

P2: A dynamically linked runtime without libfuse.so.2 passes this gate, so CI does not actually enforce the claimed static-runtime requirement. Require ldd's static/non-dynamic result rather than accepting a readelf dynamic-section result.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/native.yml, line 623:

<comment>A dynamically linked runtime without `libfuse.so.2` passes this gate, so CI does not actually enforce the claimed static-runtime requirement. Require `ldd`'s static/non-dynamic result rather than accepting a readelf dynamic-section result.</comment>

<file context>
@@ -466,17 +575,79 @@ jobs:
+          { ldd "$APPIMAGE" || true; readelf -d "$APPIMAGE" || true; } \
+            > "$PROBE" 2>&1
+          cat "$PROBE"
+          if ! grep -Eq 'statically linked|not a dynamic executable|Dynamic section|no dynamic section|NEEDED' "$PROBE"; then
+            echo "::error::neither ldd nor readelf reported a linkage verdict for $APPIMAGE (output above) — the libfuse.so.2 check would pass vacuously, so failing instead. Check that binutils is installed on this runner and that the path is the AppImage itself."
+            exit 1
</file context>

Suggested change

	if ! grep -Eq 'statically linked|not a dynamic executable|Dynamic section|no dynamic section|NEEDED' "$PROBE"; then
	echo "::error::neither ldd nor readelf reported a linkage verdict for $APPIMAGE (output above) — the libfuse.so.2 check would pass vacuously, so failing instead. Check that binutils is installed on this runner and that the path is the AppImage itself."
	exit 1
	fi
	if grep -q 'libfuse\.so\.2' "$PROBE"; then
	echo "::error::$APPIMAGE links libfuse.so.2 — the AppImage runtime is not static, so it cannot run or self-extract without libfuse2 installed. The pinned linuxdeploy-plugin-appimage in apps/native/scripts/fetch-appimage-tools.sh is stale; re-pin it there (both this workflow and release-native.yaml read that file)."
	exit 1
	fi
	if ! grep -Eq 'statically linked|not a dynamic executable' "$PROBE"; then
	echo "::error::$APPIMAGE is dynamically linked or neither ldd nor readelf could inspect it; the AppImage runtime must be static."
	exit 1
	fi

[cubic-dev-ai]

P2: Under DESKTOP_SELFTEST=1 on Linux, setup runs via block_on on the main thread (lib.rs:78). When DECOCMS_LINUX_SECURE_ORIGIN=1 forces the secure origin (the W1.9 secure-mode Linux self-test), this new install(...) call invokes window.with_webview(...) and then awaits a oneshot that only resolves once that closure runs on the GTK main thread. Because block_on blocks the very thread that must pump the WebKit event loop, the dispatch never executes and the await never returns — the self-test would hang rather than pass. Consider running the Linux secure self-test through the spawned path (as real launches do) or not awaiting a main-thread-dispatched oneshot from the block_on path, so the test cannot wedge CI.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/src-tauri/src/setup.rs, line 508:

<comment>Under `DESKTOP_SELFTEST=1` on Linux, setup runs via `block_on` on the main thread (lib.rs:78). When `DECOCMS_LINUX_SECURE_ORIGIN=1` forces the secure origin (the W1.9 secure-mode Linux self-test), this new `install(...)` call invokes `window.with_webview(...)` and then awaits a oneshot that only resolves once that closure runs on the GTK main thread. Because `block_on` blocks the very thread that must pump the WebKit event loop, the dispatch never executes and the await never returns — the self-test would hang rather than pass. Consider running the Linux secure self-test through the spawned path (as real launches do) or not awaiting a main-thread-dispatched oneshot from the `block_on` path, so the test cannot wedge CI.</comment>

<file context>
@@ -384,6 +495,26 @@ pub async fn run(app: &tauri::AppHandle) -> Result<(), SetupError> {
+            .as_ref()
+            .map(|tls| tls.leaf_cert.clone())
+            .ok_or_else(|| SetupError::WebviewTls("no local leaf certificate exists".into()))?;
+        crate::webview_trust::install(
+            &window,
+            leaf_cert,
</file context>

[cubic-dev-ai]

P2: The macOS "Package release assets" step doesn't set set -euo pipefail, unlike its Linux twin directly below. Without it, a silent failure in shasum/mv can stage a stale or empty zip.sha256 (and continue past a missing file), which the cask step later pins as the Homebrew checksum — breaking brew install --cask fleet-wide while the build still looks green. Recommend adding set -euo pipefail as the first line of this step's run: block, matching the Linux step.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At .github/workflows/release-native.yaml, line 521:

<comment>The macOS "Package release assets" step doesn't set `set -euo pipefail`, unlike its Linux twin directly below. Without it, a silent failure in `shasum`/`mv` can stage a stale or empty `zip.sha256` (and continue past a missing file), which the cask step later pins as the Homebrew checksum — breaking `brew install --cask` fleet-wide while the build still looks green. Recommend adding `set -euo pipefail` as the first line of this step's `run:` block, matching the Linux step.</comment>

<file context>
@@ -299,98 +513,291 @@ jobs:
+          # a glob over this directory.
+          STAGE="$RUNNER_TEMP/release-assets"
+          mkdir -p "$STAGE"
+          mv "$ZIP" "$DMG_OUT" "$TARGZ" "$TARGZ.sig" zip.sha256 "$STAGE/"
+
+      - name: Package release assets
</file context>

[cubic-dev-ai]

P3: An inherited object key such as toString is accepted as a platform even though no manifest entry is emitted, violating the documented exact-platform validation. Check own keys so invalid signature maps fail instead of being silently narrowed.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/native/scripts/ci/native-update-channel.mjs, line 159:

<comment>An inherited object key such as `toString` is accepted as a platform even though no manifest entry is emitted, violating the documented exact-platform validation. Check own keys so invalid signature maps fail instead of being silently narrowed.</comment>

<file context>
@@ -104,45 +104,183 @@ export function shouldPromote({
+
+  const expected = Object.keys(PLATFORM_ASSETS);
+  const unknown = Object.keys(signatures).filter(
+    (key) => !(key in PLATFORM_ASSETS),
+  );
+  if (unknown.length > 0) {
</file context>

Suggested change

	(key) => !(key in PLATFORM_ASSETS),
	(key) => !Object.hasOwn(PLATFORM_ASSETS, key),

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[github-actions]

A comment that takes a paragraph to justify a workaround is a signal the code is wrong, not the comment — fix the code, don't explain it away (CLAUDE.md).

[cubic-dev-ai]

1 issue found across 5 files (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="apps/web/public/install.sh">

<violation number="1" location="apps/web/public/install.sh:295">
P1: Re-running after installing minisign can still execute an unsigned-fallback install without ever checking its signature: this cache hit is evaluated before the minisign branch. Limit the no-download shortcut to hosts missing signature tooling, so the documented re-run actually fetches and verifies the signed tarball.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: Re-running after installing minisign can still execute an unsigned-fallback install without ever checking its signature: this cache hit is evaluated before the minisign branch. Limit the no-download shortcut to hosts missing signature tooling, so the documented re-run actually fetches and verifies the signed tarball.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At apps/web/public/install.sh, line 295:

<comment>Re-running after installing minisign can still execute an unsigned-fallback install without ever checking its signature: this cache hit is evaluated before the minisign branch. Limit the no-download shortcut to hosts missing signature tooling, so the documented re-run actually fetches and verifies the signed tarball.</comment>

<file context>
@@ -1,71 +1,433 @@
+  # A re-run against an install that already carries these exact bytes is a
+  # no-op: skip the download and only re-assert the desktop integration below.
+  INSTALLED_NEW=false
+  if [ -f "$BIN_PATH" ] && [ "$(sha256_of "$BIN_PATH")" = "$EXPECTED" ]; then
+    say "already up to date at $VERSION"
+  elif [ -z "$SIG_MISSING" ]; then
</file context>

Suggested change

	if [ -f "$BIN_PATH" ] && [ "$(sha256_of "$BIN_PATH")" = "$EXPECTED" ]; then
	if [ -n "$SIG_MISSING" ] && [ -f "$BIN_PATH" ] && [ "$(sha256_of "$BIN_PATH")" = "$EXPECTED" ]; then