From bd25486e56f3e1e395a389c1e569e075915fca1a Mon Sep 17 00:00:00 2001 From: Thore Cimbal Date: Wed, 29 Jul 2026 19:00:18 +0200 Subject: [PATCH] docs: correct Electron/desktop claim, add hostile-sender test result (Issue #19) --- .../06-moderation-content-scanning.md | 56 +++++++++++++------ 1 file changed, 39 insertions(+), 17 deletions(-) diff --git a/docs/deployment-guides/06-moderation-content-scanning.md b/docs/deployment-guides/06-moderation-content-scanning.md index 6f628c4..7453667 100644 --- a/docs/deployment-guides/06-moderation-content-scanning.md +++ b/docs/deployment-guides/06-moderation-content-scanning.md @@ -164,27 +164,49 @@ das ganze Internet wird. Fail-open bei Scanner-Fehlern, wie beim Synapse-Modul. `VideoBodyViewModel.ts`/`FileBodyViewModel.ts` (gleiches Muster wie die schon vorhandenen `DecryptError`/`DownloadError`). -**Live getestet** (2026-07-29): EICAR in verschlüsseltem Gruppenraum ("testgruppe") und in -1:1-DMs zwischen zwei echten Accounts - in beiden Fällen zuverlässig **vor dem Upload** -blockiert. Vorher (nur Synapse-Modul) lief das durch. +**Live getestet** (2026-07-29): +- EICAR in verschlüsseltem Gruppenraum ("testgruppe") und in 1:1-DMs zwischen zwei echten + Accounts - in beiden Fällen zuverlässig **vor dem Upload** blockiert. Vorher (nur + Synapse-Modul) lief das durch. +- Empfangsseite unabhängig vom Absender bestätigt: EICAR über einen echten, ungepatchten + Client (app.element.io) in denselben verschlüsselten Raum geschickt (simuliert einen + fremden/föderierten Absender ohne unseren Patch) - beim Download-/Anzeigeversuch im + gepatchten `ThreadNet-Web`-Client greift der Scanner zuverlässig. Beweist, dass der + Empfangs-Hook unabhängig vom sendenden Client funktioniert, nicht nur als Selbstschutz + für eigene Uploads. -### ⚠️ Wichtig für zukünftige Desktop-/Electron-Forks +### ⚠️ Wichtig für Desktop-/Electron-Builds (korrigiert, siehe Issue #44) -**Dieser Fix gilt nur für den Web-Client (Browser), nicht automatisch für Element Desktop.** +**Dieser Fix ist im Web-Client (Browser, das laufende `threadnet-web`-Container-Image) +bestätigt live wirksam. Ob er auch im Electron-Client wirkt, hängt am tatsächlichen +Build-Prozess - und der ist aktuell nicht automatisiert.** -Element Desktop (`apps/desktop` im selben Monorepo) ist ein Electron-Wrapper, der die -Web-App nicht selbst baut, sondern per `scripts/fetch-package.ts` ein fertiges, -**offiziell von `element-hq/element-web` signiertes Release-Tarball** herunterlädt und in -ein `webapp.asar` packt (`pnpm run fetch` → `pnpm run asar-webapp`). Ohne weitere Änderung -würde ein Desktop-Build also die **unveränderte Upstream-Version** bündeln - unsere Patches -wären nicht drin, obwohl sie im selben Monorepo liegen. +Element Desktop (`apps/desktop` im selben Monorepo) baut die Web-App nicht selbst, sondern +packt ein fertiges `webapp`-Verzeichnis in ein `webapp.asar`. *Woher* dieses Verzeichnis +kommt, hängt vom Aufrufer ab: +- **Standard-Fallback** (`pnpm run fetch ` ohne Artefakt): lädt ein offiziell von + `element-hq/element-web` signiertes Release-Tarball herunter - **Upstream, ohne unsere + Patches**. +- **Mit eigenem Build** (`webapp-artifact`-Mechanismus in `build_desktop_prepare.yaml`, + gedacht für CI): würde unseren eigenen `apps/web`-Output übernehmen, **inklusive** aller + Fork-Anpassungen. -**Für einen zukünftigen Desktop-Fork mit dieser Funktion**: `fetch-package.ts` akzeptiert -bereits eine beliebige URL statt einer Versionsnummer als Override -(`targetVersion.includes("://")`-Zweig, keine Code-Änderung nötig) - man müsste nur unseren -eigenen `apps/web`-Build als `.tar.gz` irgendwo selbst hosten (z.B. als Gitea-Release-Asset) -und `pnpm run fetch https://.../unser-build.tar.gz` statt der Standard-Versionsnummer -aufrufen. +Der zweite Weg ist im Repo als GitHub-Actions-Pipeline (`build-and-test.yaml`) angelegt, +läuft aber **nicht automatisch** - kein registrierter Runner, und der vorgelagerte Build-Job +checkt zudem noch `element-hq/element-web` (Upstream) statt des eigenen Forks aus, ein Rest +der ursprünglichen Upstream-CI. Die bereits existierende Desktop-Build (mit der +Discord-Style-Raumliste) entstand nach aktuellem Stand aus einem **manuellen, lokalen** +Build-Durchlauf, nicht aus einem reproduzierbaren, automatisierten Prozess. + +**Konsequenz für heute**: die Scan-Patches sind im `ThreadNet-Web`-Fork-Code enthalten und +würden in jedem zukünftigen (manuellen oder automatisierten) Desktop-Build aus diesem Fork +mitkommen - sie sind aber **nicht automatisch** in einer bereits existierenden +Desktop-Installation gelandet, ohne dass jemand den Build-Vorgang erneut manuell durchführt. + +Neues Backlog-Item dafür angelegt: +[Issue #44](https://rohana.axion1337.de/sorb/axion1337.chat-gitops/issues/44) - Build-Job +auf den eigenen Fork umstellen + funktionierenden Runner aufsetzen, damit Fork-Änderungen +zuverlässig und automatisch auch im Desktop-Client landen. **Element X (Mobile, iOS/Android)** ist davon komplett unberührt - eigene Codebasis auf Basis von `matrix-rust-sdk`, kein gemeinsamer Code mit `ThreadNet-Web`. Ein Schutz dort