Gate packaged Linux desktop lifecycle

[yaacovcorcos]

Summary

This draft now implements the supported, sandboxed Ubuntu packaging route instead of weakening the AppImage gate:

• publish and test a versioned x64 ".deb" installed under "/opt/Scient"
• install electron-builder's AppArmor user-namespace profile and package-managed Chromium sandbox helper
• launch the installed application as an ordinary user on Ubuntu 24.04 and inspect the real Electron process argv
• reject every form of "--no-sandbox" in the actual packaged process
• prove renderer load, folder addition, SQLite persistence, private-state permission repair, backend crash/reconnect, a second project after recovery, and full process cleanup
• use the dedicated "scient-deb" updater channel so legacy AppImage clients cannot accidentally cross-update into a Debian package
• keep AppImage as a separate diagnostic compatibility artifact whose generated AppRun is inspected and must fail closed rather than inject "--no-sandbox"

Security and product decision

Stock Ubuntu 24.04 can block the unprivileged-user-namespace probe used by an AppImage mounted at a randomized path. electron-builder 26.15.3 responds by injecting "--no-sandbox". That is not an acceptable production fallback.

The supported zero-setup Ubuntu route is therefore the installed Debian package, where package installation can establish the stable AppArmor profile and sandbox-helper ownership/mode needed by Chromium. AppImage remains an explicitly limited diagnostic artifact; this PR does not claim it is a supported stock-Ubuntu installation path.

The packaged package marker is authoritative over inherited environment variables, so a stale "APPIMAGE" variable cannot misclassify an installed Debian application. The fallback remains only for legacy packages that do not yet contain the marker.

Acceptance proof

The deep Ubuntu 24.04 acceptance job verifies:

• exact package name, version, architecture, install path, ownership, sandbox helper, and AppArmor profile
• launch as a non-root CI user under Xvfb
• actual "/proc" Electron command line contains no unexpected unsandboxed flag
• successful main-frame load and backend readiness
• fresh and pre-existing permissive profiles, including repair to private Scient permissions without changing user project permissions
• folder selection, persisted projects, controlled backend failure, one recovery, and post-recovery persistence
• stable process identity and complete descendant cleanup
• package purge after the test

The cross-platform packaged-startup verifier also requires a successful renderer main-frame load, reports load failures, sanitizes inherited launch variables, and verifies descendant cleanup rather than treating the Electron root exit as complete cleanup.

Update and release behavior

Linux release assets and checksums use "Scient--amd64.deb" plus "scient-deb-linux.yml". Release preflight rejects publication from a non-clean or historical bridge lane. The old "scient-linux.yml" AppImage updater manifest is intentionally absent so existing AppImage installations cannot silently download an incompatible format.

Before publishing this route, the website must replace its AppImage-first Linux download with an accessible Debian download and clear one-time migration instructions. We must also manually verify that an existing AppImage user's profile and conversations remain intact when launching the installed Debian package. No unsafe bridge AppImage is required or permitted.

Exact-head verification

Current pushed head: 514307e

Local exact-head checks are green:

• frozen dependency install
• focused packaging, release, updater, process, identity, and policy suites
• full "bun run test" (12/12 workspace tasks; server 2,178 passed, 7 skipped)
• full build (5/5), typecheck (9/9), formatting, release smoke, workflow validation, syntax checks, and "git diff --check"
• lint: 0 errors; 219 existing warnings

Exactly three independent final read-only reviews covered correctness/reliability, security/release safety, and architecture/product/accessibility/test proof. None found a remaining P0-P2 implementation issue. The only later changes are five narrowly scoped smoke-harness corrections: three selectors confirmed against the current Add Project component and its 14 dedicated browser tests, moving SQLite persistence inspection until after complete packaged-app shutdown, and waiting for project creation to visibly settle before inducing the controlled backend crash. No fourth review was added.

Hosted runs 30100849070, 30102650420, and 30104478299 successively proved Debian package construction, installation, sandbox launch, renderer startup, and entry through the current Add Project flow. Their logs and uploaded screenshots exposed three stale harness selectors from the retired direct-path flow: select “Local folder”, use the current “Type or browse a folder path” input, and invoke the current accessible “Open Enter” action instead of “Add”. Run 30106426996 then had Quality and every auxiliary job green; its retried package job built and installed the Debian package, launched it sandboxed, loaded the renderer, and completed folder addition before a second Node SQLite connection hit the live application database locking protocol. The harness now records the expected projects during the scenario and inspects durable SQLite state only after complete packaged-app shutdown. Run 30108288229 had Quality and every auxiliary job green. Its Debian build succeeded and the fresh-profile lifecycle passed. Diagnostics from the recovery scenario proved the harness induced its controlled crash before the asynchronous add-project flow had closed the first modal, leaving that stale modal to display the expected socket-close error; the harness now waits for the named Add Project dialog to close and the created project to become visible before crashing the backend. Implementation-head hosted run 30110128897 is fully green. Quality, release smoke, Windows process regression, and both HTML-preview platform jobs passed. The packaged Linux gate built and installed the Debian package, passed both fresh-profile and shared-group/recovery lifecycles, proved the real Electron process remained sandboxed, verified durable project state only after shutdown, confirmed controlled backend recovery and descendant cleanup, then built the diagnostic AppImage and proved its AppRun never injects a sandbox bypass. Current main (fffd9e77, curated in-app release notes) was then merged normally. The sole release-workflow conflict preserved both safeguards in their required order: release-note validation immediately after policy resolution, followed by the clean Debian-lane guard. Final-tree local tests, build, typecheck, formatting, lint, release smoke, workflow validation, and diff checks are green. Fresh exact-head hosted run 30112179302 is fully green, including Quality, Release Smoke, both HTML preview platforms, Windows process regression, the installed Debian lifecycle, and the fail-closed AppImage assertion.

Current state

This PR intentionally remains draft. Do not merge or release it until exact-head hosted CI is complete and the external website/migration prerequisite above is satisfied.

[yaacovcorcos]

Putting this PR on hold. Keep it as a draft and do not merge or restack it as-is. Resume only when the secure Linux packaging/distribution migration is intentionally scheduled; the useful packaged-acceptance work can then be carried forward against the supported package path.