The .deb and .pkg.tar.zst are not signed packages, and the in-app
update prompt has users install them by hand, so nothing checked them.
A new checksums job hashes the Linux downloads into SHA256SUMS.txt,
signs it with the updater's minisign key (tauri signer) and uploads
SHA256SUMS.txt + SHA256SUMS.txt.minisig. The README shows the
verify-then-install command.
Refs #36
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
On stock GNOME there is no StatusNotifier host, so choosing "Keep
running in the tray" hid the window with no icon to bring it back.
Expose whether org.kde.StatusNotifierWatcher has an owner on the
session bus (always true off Linux); cinny's dialog then defaults to
Quit and words the other option as "running in the background".
Refs #37
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
The README was upstream's: its download buttons and minisign key pointed
at cinnyapp releases, so following it installed upstream Cinny and
verified it against the wrong key. Point downloads at this repo's
releases (NSIS exe, .deb, pacman package, AppImage), publish Lotus'
updater key, and list the desktop features.
Fixes#35
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
The desktop CSP listed only known embed hosts in frame-src, so every
room widget that is not one of them (Jitsi, Etherpad, Grafana, bots)
showed a blank frame; the web deploy allows https: frames (#205).
Match it. Widget frames are sandboxed by cinny and same-origin widget
URLs are refused (isWidgetUrlSafe), so this does not widen what a
widget can do to the app.
Fixes#33
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017PCb59uY3UKqDqt7B6hzd5
On CachyOS the in-app update failed with "Permission denied (os error 13)
at path /usr/bin/tauri_current_app…": the app was installed from the
Arch package, and Tauri's Linux updater can only replace an AppImage — for
anything else it tries to write next to the binary in /usr/bin.
- update_install_kind command: "in-app" on Windows and for an AppImage
($APPIMAGE set); on Linux package installs "pacman" (ID/ID_LIKE arch:
Arch, CachyOS, Manjaro, EndeavourOS…), "deb" (debian/ubuntu and
derivatives) or "manual". The web UI shows the matching update command.
- install_update refuses up front on a package install
("install: package-managed (…)") instead of downloading the whole
update and failing at the last step.
Tests: CachyOS/Arch → pacman; Ubuntu/Debian/Mint → deb; Fedora/unknown →
manual; AppImage and Windows → in-app.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
The example.com check could pass vacuously if the runner can't reach the
internet (goto failed silently, the mic request then came from the app's
own page). Serve a page on http://localhost:9333 instead, confirm the
navigation happened, and fail on builds that should refuse it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
The CI VM has no microphone (getUserMedia → NotFoundError). With
LOTUS_WEBVIEW2_DEBUG_PORT set the app also passes
--use-fake-device-for-media-stream; permission requests still go through
the real PermissionRequested handler.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
WebView2's WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS is ignored because the app
sets its browser arguments explicitly (seen on the runner: the WebView2
command line had only the app's arguments). The app now appends
--remote-debugging-port only when LOTUS_WEBVIEW2_DEBUG_PORT holds a valid
port (>= 1024); otherwise the arguments are exactly as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Adds the same `statusPages` entry the web app uses, so the desktop app
shows the status banner for matrix.lotusguild.org too (Kuma status page
https://isitup.lotusguild.org/status/matrix). The desktop CSP already
allows https: connections; no other change is needed. Inert until the
bundled cinny includes the banner (cinny PR #255).
Tested on a Linux release build: with a local fake Kuma reporting calls
down, the desktop app shows "Voice calls are down right now. Messages
still work." and polls both endpoints; from inside the desktop app the
real Kuma page answers 200 on both (CSP and CORS allow it).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Commands for the web client to keep a copy of the login tokens in the OS
keychain: secure_session_supported / _set / _get / _clear.
- Windows: Credential Manager via the keyring crate (3.6, windows-native),
entry "session" in service "Lotus Chat". Only the secrets are stored
(userId, deviceId, accessToken, refreshToken); the serialized value is
capped at 1200 chars (Windows' limit is 2560 bytes).
- Other platforms: supported = false and the other commands answer "not
supported on this platform" (Linux Secret Service can prompt to unlock a
wallet at startup; that needs its own testing). No new Linux dependency:
without a platform feature the crate only has its mock store.
- Keychain calls run on the blocking pool, off the main thread.
Step 1 is a mirror only (the web client still reads its session from
localStorage); see the cinny PR.
Tests: round trip + clear, clearing an empty keychain, incomplete and
oversized sessions rejected with nothing written, the JSON shape the web
client sends, a realistic OIDC session fits (keyring's mock store). Linux
release build: commands answer as designed and login is unaffected.
Windows: type-checked only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
The bundled Element Call page ran on the app's own origin
(http://localhost:44548), so the call frame could read the app's storage
(login token) and DOM. Serve it from http://127.0.0.1:44548 instead: the
same local server and bundle, a different origin.
- The local server binds 127.0.0.1 explicitly. The app is still loaded as
http://localhost:44548 (its storage stays where it is; the engines try
127.0.0.1 for `localhost`). Binding the name `localhost` could pick ::1
only (Windows lists it first), and then 127.0.0.1 wouldn't answer.
- config.json: desktopCallOrigin = http://127.0.0.1:44548. cinny loads the
call page from there only when this is set (cinny #43 PR).
- CSP frame-src allows http://127.0.0.1:44548.
- Permissions (on top of #22): the call page's origin gets microphone/
camera/screen only; nothing else.
- The call page gets no IPC: the capability only matches
http://localhost:44548.
Tested (Linux release build): the server listens on 127.0.0.1:44548 and
the app loads as http://localhost:44548; the call page loads from
127.0.0.1 inside the app under its CSP; from that frame parent.localStorage
and parent.document are SecurityError, while a same-origin frame (the old
setup) reads the app's storage. The call itself was tested in a simulated
desktop (Chromium, the WebView2 engine) against a local Synapse + LiveKit;
see the cinny PR. Rust tests 17 passed; Windows code type-checked.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Linux (WebKitGTK) allowed every permission request of every kind; Windows
(WebView2) auto-allowed mic/camera/notifications without checking who asked.
Now (src-tauri/src/webview_permissions.rs, unit-tested):
- Linux: microphone/camera/screen, device labels, notifications and location
are granted when the page in the window is the app
(http://localhost:44548; debug builds also the bundled/dev page).
Everything else is denied (WebKitGTK has no prompt of its own). WebKitGTK
doesn't say which frame asked; frames are gated earlier by the Permissions
Policy (cinny gives microphone/camera only to the same-origin call frame).
- Windows: the same grants (minus location, which keeps WebView2's prompt),
checked against the origin of the frame that asked (args.Uri()). Other
origins are denied mic/camera/notifications/location; other kinds keep
WebView2's default handling.
- Denials are logged ("webview: denied …").
Tested on Linux with a release build under Xvfb + PulseAudio (no WebDriver:
WebKit's automation mode bypasses the handler), before/after:
- app page: mic, device labels, location allowed (unchanged)
- same-origin call frame: mic allowed (unchanged)
- cross-origin frame without allow=: blocked before the handler (unchanged)
- foreign top-level page: mic, device labels, location now denied (were
allowed)
Real cinny build: boots, logs in, no denials. Windows code type-checked
(x86_64-pc-windows-gnu).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Lotus CIandClaude Opus 5.5
jared