12 commits

Author	SHA1	Message	Date
Daniel Maksymilian Syrnicki	e68ed279cc	fix(https): make HTTPS opt-in to stop the BAD_SIGNATURE trap on fresh installs ... Every Furtka since 26.5 shipped a Caddyfile with a `__FURTKA_HOSTNAME__.local { tls internal }` site block, so every first boot auto-generated a fresh self-signed CA + intermediate + leaf. That worked for the first-ever Furtka user, but every reinstall (or second box on the same LAN) produced a new CA whose intermediate shared the fixed CN `Caddy Local Authority - ECC Intermediate` with the previous one. Firefox caches intermediates by CN across profiles — even private windows share cert9.db — so any visitor who had trusted an older Furtka's CA got a cached intermediate with mismatched keys when they hit the new box, producing `SEC_ERROR_BAD_SIGNATURE`. Unlike UNKNOWN_ISSUER, Firefox has NO "Advanced → Accept Risk" bypass for BAD_SIGNATURE, so fresh-install boxes were effectively unreachable over HTTPS in any browser that had ever seen a previous Furtka. Validated live on the .46 test VM: fresh 26.14 ISO install → Firefox hits BAD_SIGNATURE on https://furtka.local/ (even in private mode). Chromium bypasses it via mDNS failure but the issue is the same. openssl verify on the box confirms the chain is internally valid — this is purely client-side cache pollution across boxes. Fix: - assets/Caddyfile: removed the hostname site block. Default install serves :80 only — https://furtka.local connection-refuses, which is a normal error every browser handles instead of the unbypassable crypto fault. Added top-level import of /etc/caddy/furtka-https.d/*.caddyfile so the /settings HTTPS toggle can drop a listener snippet there when a user explicitly opts in. - furtka/https.py: set_force_https now writes TWO snippets atomically — the top-level hostname + tls internal block (enables :443) and the :80-scoped redirect (forces HTTP→HTTPS). Disable removes both. Reload failure rolls both back. Added _read_hostname + _https_snippet_content helpers with `/etc/hostname` → 'furtka' fallback so a missing hostname file doesn't produce an empty site block Caddy rejects. - furtka/https.py::status: force_https now reads the listener snippet (was reading the redirect snippet). A redirect without a listener isn't actually HTTPS being served, so the listener is the authoritative "HTTPS is on" signal. - furtka/updater.py: new _maybe_migrate_preserve_https hook runs inside _refresh_caddyfile on the 26.14 → 26.15 transition. If the box had the redirect snippet on disk (user had opted into HTTPS under the old regime), it writes the new listener snippet too so HTTPS keeps working after the Caddyfile swap removes the hostname block. - webinstaller/app.py: post-install creates /etc/caddy/furtka-https.d/ alongside /etc/caddy/furtka.d/ so the glob import can't trip an older Caddy on a missing path during the first reload. Live-tested on .46: set_force_https(True) writes both snippets, Caddy reloads, :443 listener comes up with fresh CA, curl -k returns 302, HTTP 301-redirects. set_force_https(False) removes both snippets atomically, :443 goes back to connection-refused. Tests: test_https.py expanded from 13 to 15 cases. Toggle-on asserts both snippets written + hostname substituted. Toggle-off asserts both removed. Rollback cases verify BOTH snippets restore on reload failure. New test_https_snippet_content_has_tls_internal_and_routes locks the exact shape of the listener block. test_webinstaller_assets.py: updated two old asserts that assumed hostname block was in Caddyfile; new test_post_install_creates_https_snippet_dir guards the new directory. 276 tests pass, ruff check + format clean. Known remaining wart (documented in CHANGELOG): a browser that trusted a prior Furtka CA still hits BAD_SIGNATURE on this box's HTTPS after enabling it, because the fixed intermediate CN is a Caddy-side limitation. Workaround: clear cert9.db or visit in a fresh profile. Won't affect end users with one Furtka box ever. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-21 19:30:04 +02:00
Daniel Maksymilian Syrnicki	26f0424ae3	fix: auth-guard / and /settings, add Logout link to static navs ... Since 26.11 shipped login, two of the three nav pages were secretly unauthenticated. The Caddyfile only reverse-proxied /api/*, /apps*, /login*, /logout* to the Python auth-gated handler. Everything else — including / (landing page) and /settings/ — fell through to Caddy's catch-all file_server straight out of assets/www/, skipping the session check entirely. LAN visitor effect: they could read the box's hostname, IP, Furtka version, uptime, and see all the Update-now / Reboot / HTTPS-toggle buttons on /settings/. The API calls those buttons fired were themselves 401-gated so nothing actually happened — but the info leak plus "looks open" UX was real. Caught in the 26.13 SSH test session when the user noticed Logout only appeared in the nav on /apps, and not on / or /settings/. Fix: - Caddyfile: new `handle /settings*` and `handle /` blocks in the shared `(furtka_routes)` snippet reverse-proxy to localhost:7000, so both hit the Python auth-guard before the HTML goes out. - api.py: new `_serve_static_www(relative_path)` helper reads assets/www/{index.html, settings/index.html} with a path-traversal clamp (resolved path must stay under static_www_dir). `do_GET` routes `/` and `/settings[/]` to it. Removed the `/` branch from the old combined-with-/apps line — those are different pages now. - paths.py: new `static_www_dir()` helper with `FURTKA_STATIC_WWW` env override for tests. - assets/www/*.html: both nav bars get the Logout link + a shared `doLogout()` inline script matching the _HTML pattern. Users never see the link unauthed (the Python handler 302s them before the page renders), but authed users get consistent navigation across all three pages. Tests: 5 new cases in test_api.py — unauth / redirects, unauth /settings redirects (both trailing-slash and not), authed / serves index.html, authed /settings serves settings/index.html, regression guard that / and /apps serve different content. Existing test updated (the one that used / as a proxy for /apps). Static /style.css, /rootCA.crt, /status.json, /furtka.json, /update-state.json stay served by Caddy's catch-all — those are public by design (login page needs style.css, fresh users need the CA to trust HTTPS, runtime JSON is metadata not creds). 272 tests pass, ruff check + format clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-21 18:16:42 +02:00
Daniel Maksymilian Syrnicki	470823b347	feat(auth): login-guard the Furtka UI with a cookie session ... One-admin, one-password model — all of /apps, /api/*, /, and /settings/ now require a signed-in session. Passwords are werkzeug PBKDF2-hashed in /var/lib/furtka/users.json (mode 0600, atomic write via the same .tmp+chmod+rename dance installer.write_env uses). Sessions are secrets.token_urlsafe(32) tokens held in a module-level SessionStore dict (thread-safe lock included for when we swap to ThreadingHTTPServer). Cookies are HttpOnly, SameSite=Strict, and Path=/, with Secure set when X-Forwarded-Proto from Caddy says HTTPS. Two bootstrap paths: * Fresh install — webinstaller step-1 collects Linux user + password, the chroot post-install step hashes the password and writes users.json on the target partition. First browser visit lands on /login with the account already present. * Upgrade from 26.10-alpha — no users.json yet, so /login detects setup_needed() and renders a first-run setup form. POST creates the admin and immediately logs in. POST /logout revokes the server session and clears the cookie. Unauthenticated HTML requests 302 to /login; unauthenticated API requests 401 JSON so fetch() callers see a clean error. A sleep(0.5) on failed logins is the brute-force speed bump on top of werkzeug's ~600k-iter PBKDF2. Caddyfile gains /login* and /logout* handle blocks in the shared furtka_routes snippet so both :80 and the HTTPS hostname block forward the auth endpoints to localhost:7000. Without this Caddy would 404 from the static file server. Test surface: * tests/test_auth.py (new, 19 cases): hash roundtrip, users.json I/O, session create/lookup/expire/revoke. * tests/test_api.py: new admin_session fixture; existing HTTP tests updated to send the cookie; new tests cover login setup, login success, wrong-password 401, logout revocation, and the guard's 302/401 split. * tests/test_webinstaller_assets.py: new case that unpacks the users.json _write_file_cmd body and verifies the werkzeug hash round-trips against the step-1 password. Bumped version to 26.11-alpha and rolled CHANGELOG. Also folded in the ruff-format fix that was pending from 26.10-alpha's lint red. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-21 13:01:17 +02:00
Daniel Maksymilian Syrnicki	c7e7c8b1e5	chore: release 26.9-alpha ... Three small fixes surfaced by the 26.8 QA pass on fresh VM .161: - Landing-page app tiles now open external `open_url` links in a new tab, matching /apps Open-button behaviour. Without this a Kuma click on the home screen replaced Furtka itself. - `scripts/publish-release.sh` treats the ISO upload as best-effort; a Forgejo-proxy 504 no longer kills the whole release after tarball + sha + release.json are already uploaded. - `furtka app list --json` now mirrors /api/apps — includes `description_long`, `open_url`, and `settings` that the previous slim projection dropped.	2026-04-20 18:51:30 +02:00
Daniel Maksymilian Syrnicki	cf93ef44cb	chore: release 26.8-alpha (power actions, supersedes orphan 26.7 tag) ... Adds Reboot + Shut down buttons on /settings, backed by a new POST /api/furtka/power endpoint that kicks a delayed `systemd-run --on-active=3s systemctl {reboot|poweroff}` so the HTTP response flushes before the kernel loses network. Both buttons open a native confirm dialog; after reboot, the page polls /furtka.json until the box is back and reloads itself. 26.7-alpha was tagged on 5d8ac63 but release.yml never fired for that tag (Forgejo race with the concurrent main push; re-push of the deleted tag didn't wake the workflow either). 26.8 supersedes it and carries the same open_url + Open-button content plus the power actions. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 16:00:19 +02:00
Daniel Maksymilian Syrnicki	5d8ac63d9f	chore: release 26.7-alpha ... Ships the open_url manifest field + the Open button in /apps and on the landing page, replacing the fileshare-only hardcoded deep-link with a generalised {host}-templated URL. Fileshare seed manifest bumps to 0.1.2; the furtka-apps catalog release that goes with this adds matching open_url values for fileshare + uptime-kuma. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 15:44:01 +02:00
Daniel Maksymilian Syrnicki	3a8fad5185	feat(catalog): on-box apps catalog synced independently of core version ... New `furtka catalog sync` pulls the latest daniel/furtka-apps release, verifies its sha256, extracts under /var/lib/furtka/catalog/, and atomically swaps into place — so apps can ship without cutting a new Furtka core release. A daily timer (furtka-catalog-sync.timer, 10 min post-boot + 24 h with ±6 h jitter) drives the sync; /apps gets a manual "Sync apps catalog" button that kicks the same code path via a detached systemd-run unit. Layout of the new on-box tree: /var/lib/furtka/catalog/ synced catalog (survives self-updates) ├── VERSION └── apps/<name>/ ... /var/lib/furtka/catalog-state.json sync stage + last version, UI-polled /run/furtka/catalog.lock flock so timer + manual click can't race Resolver precedence (furtka/sources.py): catalog wins over the bundled seed (/opt/furtka/current/apps/, carried by the core release for offline first-boot). Installed apps under /var/lib/furtka/apps/ are never auto- swapped — user clicks Reinstall to move an existing install onto a newer catalog version; settings merge-preserved via the existing installer.install_from path. New files: - furtka/_release_common.py — shared Forgejo/tarball primitives lifted from furtka/updater.py. Both modules now import from here; updater's behaviour and public API unchanged. - furtka/catalog.py — check_catalog(), sync_catalog() with staging + manifest validation + atomic rename. Refuses bad sha256 / broken manifests and leaves the live catalog intact on any failure path. - furtka/sources.py — resolve_app_name() / list_available() abstraction used by installer.resolve_source and api._list_available. - assets/systemd/furtka-catalog-sync.{service,timer} — oneshot service + daily timer. Timer auto-enables on self-update via a one-line addition to _link_new_units (fresh installs get enabled via the webinstaller's _FURTKA_UNITS list). API + UI: - /api/bundled renamed internally to _list_available; endpoint stays as a backcompat alias; /api/apps/available is the new canonical name. Each list entry carries a `source` field ("catalog" | "bundled"). - POST /api/catalog/sync/check + /apply + GET /api/catalog/status. - /apps page grows a catalog-status row + Sync button; poll loop mirrors the Furtka self-update flow. CLI: `furtka catalog sync [--check]` + `furtka catalog status` (both support --json). Old `furtka app install` / `reconcile` / `update` / `rollback` surfaces are unchanged. Test gate: 194/170 baseline + 24 new tests covering catalog sync (happy path, sha256 mismatch, invalid manifest, lock contention, preserves-on-failure) + resolver precedence + api renames. ruff check + format clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 14:16:02 +02:00
Daniel Maksymilian Syrnicki	e7ee1698bd	fix(ui): stop SHA-256 fingerprint overflowing the Local HTTPS card ... The /settings "CA fingerprint (SHA-256)" value is a 95-char colon- separated hex string with no whitespace, so CSS had no valid break points and the value pushed past the card's right edge — visible on the 192.168.178.23 fresh-install test. .kv is a two-column grid (max-content 1fr); grid items default to min-width: auto (= content width), which overrides the 1fr track's width constraint. min-width: 0 lets the track shrink, and overflow-wrap: anywhere gives the fingerprint valid break points at any character. The styling stays scoped to .kv dd so card prose isn't affected. Verified live on .23 via hot-patch into /opt/furtka/current/assets/ www/style.css + caddy reload. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 13:41:33 +02:00
Daniel Maksymilian Syrnicki	8fbe67ffb9	fix(https): restore TLS handshake — name hostname + correct PKI path ... Closes #10. Two linked bugs in 26.4-alpha's Phase 1 HTTPS made the force-HTTPS toggle fatal: every SNI handshake on :443 died with SSL_ERROR_INTERNAL_ERROR_ALERT, so the toggle redirected users from working HTTP to broken HTTPS. Root cause 1: bare `:443 { tls internal }` gives Caddy no hostname to issue a leaf cert for, so /var/lib/caddy/certificates/ stayed empty and Caddy sent TLS `internal_error` on every handshake. Fix: the :443 block is now `__FURTKA_HOSTNAME__.local, __FURTKA_HOSTNAME__ { tls internal }`, with the marker substituted by webinstaller/app.py at install time and by furtka.updater._refresh_caddyfile on self-update (reads /etc/hostname, falls back to "furtka"). `auto_https disable_redirects` keeps Caddy's built-in redirect out of the way of the /settings toggle. Root cause 2: furtka/https.py and the /rootCA.crt handler both referenced /var/lib/caddy/.local/share/caddy/pki/authorities/local/ — a path that doesn't exist. caddy.service sets XDG_DATA_HOME=/var/lib, so Caddy's storage is /var/lib/caddy/ directly. Fix: both paths corrected. Verified on the 192.168.178.110 smoke VM by swapping the Caddyfile in, reloading, handshaking, restoring: TLS 1.3 handshake succeeds, leaf cert issued under /var/lib/caddy/certificates/local/, /rootCA.crt returns 200. Tests: new cases assert the Caddyfile ships the hostname placeholder, the webinstaller substitutes it, _refresh_caddyfile re-substitutes from /etc/hostname on update, and the asset sets auto_https disable_redirects. Unit tests still stub the Caddy reload — the real handshake regression needs a smoke-VM integration test (follow-up, separate from this fix). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-20 11:39:48 +02:00
Daniel Maksymilian Syrnicki	663bd74572	feat(https): local HTTPS via Caddy tls internal + opt-in redirect toggle ... Caddy now serves both :80 (plain HTTP, unchanged default) and :443 with tls internal — it generates its own per-box root CA on first start, stored under /var/lib/caddy/.local/share/caddy/pki/authorities/local/. Users can download rootCA.crt at /rootCA.crt (served on both listeners) and install it per-OS via the new /https-install/ guide. Settings page grows a Local HTTPS card with CA fingerprint, download button, reachability probe, and an opt-in "force HTTPS" toggle. The toggle only unhides itself once the current browser already trusts the cert, so enabling it can't lock the user out of the settings page. Backend: GET /api/furtka/https/status and POST /api/furtka/https/force in furtka.https. The force toggle drops a Caddy import snippet into /etc/caddy/furtka.d/redirect.caddyfile and reloads Caddy; reload failure rolls the snippet state back so a bad config can't wedge the next service start. updater._refresh_caddyfile() ensures /etc/caddy/furtka.d exists before every reload so 26.3-alpha → 26.4-alpha self-updates don't trip on the new glob import directive. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-17 12:19:06 +02:00
Daniel Maksymilian Syrnicki	a5de3d7622	fix(settings): close the two self-update UX gaps from 2026-04-16 VM test ... Drive upd-current from the /api/furtka/update/check response so a post-update Check reflects the new installed version without Ctrl+F5, and arm a 45s fallback location.reload on apply-click so the page still comes up on the new version when the mid-apply API restart drops the /update-state.json poll before stage=done is observed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-17 09:22:34 +02:00
Daniel Maksymilian Syrnicki	c080764c7e	fix(furtka): move assets/ to repo top level so Caddy + systemd find it ... Root cause of today's 403 on a fresh install: assets/ lived inside the Python package at furtka/assets/, so the resource-manager tarball extracted to /opt/furtka/versions/<ver>/furtka/assets/. But Caddyfile has `root * /opt/furtka/current/assets/www`, systemd units point at /opt/furtka/current/assets/bin/furtka-status, and the install-time `systemctl link /opt/furtka/current/assets/systemd/*.service` expected the top-level layout. All three found nothing: - Caddy → 403 Forbidden (empty/missing document root) - systemctl link → silent no-op, nothing ever linked into /etc/systemd/system/ - furtka-api.service + furtka-reconcile.service → "inactive" because they were never registered Nothing in the Python package ever imported furtka.assets — these are shell scripts, HTML/CSS, systemd units, and a Caddyfile, which is config data, not package data. Promoting assets/ to the repo root matches how it's referenced everywhere downstream and eliminates the path mismatch. Changes: - git mv furtka/assets assets - iso/build.sh: tarball-staging step now also `cp -a "$REPO_ROOT/assets"` so the tarball ships ./assets at its root, and the live-ISO copy reads from $REPO_ROOT/assets instead of $REPO_ROOT/furtka/assets. - scripts/build-release-tarball.sh: same for release tarballs. - webinstaller/app.py: _resolve_assets_dir's dev fallback walks one level up to REPO_ROOT/assets/. - tests/test_webinstaller_assets.py: ASSETS constant updated. Tests still green (150/150) because both paths were fs-level — no code imports changed. Next ISO build will land assets at the path everything downstream expects. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-16 15:26:10 +02:00