Thore Cimbal
5297104846
The issue insists on measuring before building, so: the import was Element Web 1.12.17 in May, upstream is at v1.12.26, and GHSA-wrcp-5v3v-3j6v has been open since 2026-07-20 with "affected: < v1.12.22". We are inside that range. The other five advisories concern 1.11.x and do not. Severity is medium and the attack needs the client pointed at a malicious homeserver, which our users have no reason to do. But the precondition is reachable: disable_custom_urls is not set, so Element accepts an arbitrary homeserver by default, and the desktop builds are handed out. So the honest answer is overdue rather than urgent: a fork without a merge path took four weeks to not close a known hole, which is exactly the latency this issue names as the real problem. One mitigation is available today and independent of the fork question - setting disable_custom_urls removes the precondition for our users in one line. With federation closed it is a reasonable setting on its own merits.
4.7 KiB
type, id, status, created, milestone, priority, projekt, gitlab_iid, related
| type | id | status | created | milestone | priority | projekt | gitlab_iid | related |
|---|---|---|---|---|---|---|---|---|
| issue | 0099 | open | 2026-08-06 | M1 | medium | threadnet-web | 12 |
Upstream-Sicherheitsfixes lassen sich nicht mergen — kein gemeinsamer Vorfahre
Adoptiert aus threadnet-web#12 (2026-08-18, ADR-0019). Kommentare und Verlauf bleiben dort; kanonisch ist ab jetzt diese Datei.
Am 2026-08-06 gemessen (docs/axion1337-fork.md, Abschnitt 4): Dieses Repo hat keine Upstream-Historie. Element Web 1.12.17 kam am 2026-05-10 als kompletter Baum herein — in 3da3635, im selben Commit wie das erste eigene Feature.
Damit gibt es keinen gemeinsamen Vorfahren mit element-hq/element-web. git merge upstream/develop ist nicht möglich; erzwungen kollidiert praktisch jede Datei.
Warum das ein Sicherheitsthema ist, kein Build-Thema
Element veröffentlicht Sicherheitsfixes als neue Version. Bei einem normalen Fork zieht man sie mit einem Merge. Bei uns bedeutet dasselbe: neuen Upstream-Stand beschaffen und unsere 12 Patches von Hand neu auftragen — davon sieben in der Medien-Pipeline, wo Element gerade auf MVVM umbaut.
Das ergibt eine unangenehme Kette mit gitops#22 (Advisory-Monitoring): Wir würden von einer Lücke erfahren und wären trotzdem langsam. Die Zeitspanne zwischen „bekannt" und „gepatcht" ist das, was zählt — und sie ist hier strukturell zu lang.
⚠️ Verschärfend: Verschiebt Element beim MVVM-Umbau eine der viewmodels/-Dateien, entsteht kein Konflikt — unsere Zeilen sind schlicht weg, und Git meldet nichts.
Was zu tun ist
- Zuerst messen, nicht bauen: Auf welchem Stand ist Upstream inzwischen, und sind seit 1.12.17 Sicherheitsfixes für Element Web erschienen? Das beantwortet, ob das dringend ist oder Vorsorge.
element-hq/element-webals zweiten Remote aufnehmen und den Tag von 1.12.17 holen. Damit lässt sich ein Update wenigstens als Diff betrachten, statt blind zu kopieren.- Prüfen, ob sich ein gemeinsamer Vorfahre nachträglich herstellen lässt — ein Graft/Replace des Import-Commits auf den passenden Upstream-Tag. Wenn das trägt, sind künftige Updates wieder ein Merge.
- Falls nicht: einen Ablauf schreiben, wie unsere 12 Patches auf einen neuen Stand aufgetragen werden — mit dem Funktionstest für ClamAV als Abnahme (verschlüsselte Datei senden, abgelehnte empfangen).
Zusammenhang: gitops#22 (Advisory-Monitoring) ist die Erkennung, dieses Issue die Reaktionsfähigkeit. Das eine nützt wenig ohne das andere.
Gefunden am 2026-08-06 beim Vermessen der Merge-Reibung (Arbeitspaket 3 aus #7).
Schritt 1 beantwortet 2026-08-19 — es ist keine Vorsorge mehr
Das Issue verlangt ausdrücklich „zuerst messen, nicht bauen". Gemessen:
Wir sind neun Veröffentlichungen zurück. Import war Element Web 1.12.17 (2026-05-10); Upstream steht bei v1.12.26 (2026-08-18).
Und es gibt eine offene Sicherheitsmeldung, die uns betrifft:
| Advisory | GHSA-wrcp-5v3v-3j6v |
| veröffentlicht | 2026-07-20 (vier Wochen offen) |
| Einstufung | medium |
| Inhalt | Ein bösartiger Homeserver kann über die Startseite HTML in Element Web einschleusen |
| betroffen | < v1.12.22 — wir laufen 1.12.17 |
Die übrigen fünf Advisories im Projekt betreffen ältere Stände (≤ 1.11.x) und damit nicht uns.
Einordnung — real, aber schmal
Der Angriff setzt voraus, dass der Client auf einen bösartigen Homeserver zeigt. Unsere Nutzer verwenden ihn gegen den eigenen Server, und Föderation ist seit ADR-0021 geschlossen.
Aber die Voraussetzung ist erreichbar: disable_custom_urls ist in
element-values.yaml nicht gesetzt, Element erlaubt damit standardmäßig die
Eingabe eines beliebigen Homeservers — und die Desktop-Builds werden verteilt. Wer
sich mit unserem Client woanders anmeldet, ist ungeschützt.
Was daraus folgt
Die Antwort auf „dringend oder Vorsorge" lautet: weder Panik noch Vorsorge, sondern überfällig. Ein Fork ohne Merge-Weg hat vier Wochen gebraucht, um eine bekannte Lücke nicht zu schließen — genau die Zeitspanne, die dieses Issue als das eigentliche Problem benennt.
Sofort möglich, unabhängig vom Merge-Problem: disable_custom_urls: true setzen.
Das nimmt dem Advisory für unsere Nutzer die Voraussetzung, kostet eine Zeile und
berührt die Fork-Frage nicht. Ob fremde Homeserver überhaupt erlaubt sein sollen, ist
ohnehin eine eigene Entscheidung — bei geschlossener Föderation liegt „nein" nahe.
Schritte 2–4 (Upstream als Remote, Graft-Versuch, Patch-Auftragsverfahren) bleiben offen; sie sind der eigentliche Umfang dieses Issues.