Files

T

Thore Cimbal d82b8d517a docs(issues): #0099 - disable_custom_urls set in both clients, with its limits stated

Decision sorb, and it needed two files rather than one: the desktop client loads its
own config.json, so changing only element-values.yaml would have hardened the web
client and left the distributed builds alone - the themes-rollout trap again.

Read out of our own code rather than assumed: the edit button beside the server name
disappears, and the 401/403 login error names the server. That is a surface
restriction. MatrixChat still accepts hs_url from the query string in two registration
flows without consulting the setting, so a crafted link is untouched.

Recorded as a narrowing, not a mitigation. GHSA-wrcp-5v3v-3j6v still applies to
1.12.17 and the upstream update in steps 2-4 remains the actual fix.

2026-08-19 12:00:00 +00:00

6.4 KiB

Raw Blame History

type, id, status, created, milestone, priority, projekt, gitlab_iid, related

type

status

created

milestone

priority

projekt

gitlab_iid

issue

0099

open

2026-08-06

medium

threadnet-web

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-web als 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.

Teilmaßnahme 2026-08-19 — `disable_custom_urls` an beiden Stellen

Entscheidung sorb. Gesetzt in zwei Dateien, nicht in einer:

Ort	Datei	Commit	wirksam
Web-Client	`gitops:apps/production/custom-configs/element-values.yaml`	`d809b3f`	mit dem Flux-Abgleich (Element liest `config.json` beim Laden)
Desktop-Client	`ThreadNet-Web:apps/desktop/axion1337/config.json`	`e1e9a19`	erst mit dem nächsten Desktop-Build

Die zweite Stelle wäre fast durchgerutscht: Der Desktop-Client lädt seine eigene config.json, nicht die des Web-Deployments — derselbe Fallstrick wie beim Themes-Rollout. Eine Änderung nur in element-values.yaml hätte den Web-Client abgesichert und genau die Builds unberührt gelassen, die verteilt werden.

Was sie bewirkt — und was nicht

Im Code unserer Fassung nachgelesen, nicht angenommen:

ServerPicker.tsx: Der „Bearbeiten"-Knopf am Servernamen wird nicht gerendert. Über die Oberfläche ist der Homeserver damit nicht mehr wechselbar.
ErrorUtils.tsx: Bei 401/403 benennt die Fehlermeldung den Server, statt generisch zu bleiben — kleiner Nebengewinn für den Alltag.

⚠️ Es ist eine Oberflächen-Sperre, keine technische. MatrixChat.tsx übernimmt hs_url weiterhin aus der URL — in zwei Registrierungs-Flüssen (mobile Registrierung, Bestätigungslink) und ohne disable_custom_urls zu prüfen. Ein präparierter Link bleibt davon unberührt.

Für GHSA-wrcp-5v3v-3j6v heißt das: Der bequeme, sichtbare Weg zu einem fremden Homeserver ist weg, alle Wege sind es nicht. Die Maßnahme senkt die Wahrscheinlichkeit, dass jemand versehentlich oder auf Zuruf woanders landet — sie ist kein Ersatz für das Upstream-Update. Das bleibt Schritt 2–4 dieses Issues.

6.4 KiB Raw Blame History Unescape Escape