Files

T

Thore Cimbal 8c07c365f6 docs(issues): #0099 step 2 - the remote is in place and it contradicts the premise

upstream is configured and both tags are fetched, so updates can finally be looked at
as a diff. The first diff disproved what this issue and the fork doc have both said
since August: the import is not the v1.12.17 tag. 783 files differ, 115 exist only on
our side, and two of them date the tree - TextualBodyViewModel.tsx and
RovingTabIndex.tsx are absent from the tag, present in v1.12.26 and present in our
import. The changelog stops at 1.12.17 only because it is written at release time.

So the base is a develop state after the 1.12.17 release. Fittingly it is the MVVM
files that prove it - the area this issue already warned about.

Step 3 changes accordingly: grafting onto v1.12.17 would put every future merge on an
invented ancestry, and worse than raising false conflicts, it could hide real ones.
Finding the actual ancestor means searching develop history, which needs the full
upstream repository rather than a shallow tag fetch.

The advisory assessment is unchanged - the base sits below 1.12.22 either way.

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

8.6 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.

Schritt 2 erledigt 2026-08-19 — und er widerlegt eine Annahme des Issues

upstream (element-hq/element-web) ist als zweiter Remote eingerichtet, v1.12.17 und v1.12.26 sind flach geholt. Der Remote ist lokale Konfiguration und wird nicht mitcommittet; die Einrichtung steht jetzt in ThreadNet-Web:docs/axion1337-fork.md (Commit fa5dcc5).

Der Import ist NICHT der Tag `v1.12.17`

Das Issue und die Fork-Doku behaupteten beide, „Element Web 1.12.17 kam am 2026-05-10 als kompletter Baum herein". Die erste Messung mit dem neuen Remote widerspricht dem:

Messung	Ergebnis
`git diff --stat v1.12.17 3da3635`	783 Dateien, +17443 / −10371
nur bei uns vorhanden	115 Dateien
nur im Tag vorhanden	62 Dateien

Entscheidend sind zwei davon, weil sie datieren: apps/web/src/viewmodels/room/timeline/event-tile/body/TextualBodyViewModel.tsx und packages/shared-components/src/core/roving/RovingTabIndex.tsx — im Tag v1.12.17 nicht vorhanden, in v1.12.26 und in unserem Import vorhanden. Der CHANGELOG.md unseres Imports endet bei 1.12.17 (2026-04-30), weil er erst beim Release fortgeschrieben wird.

Die Grundlage ist also ein develop-Stand nach dem 1.12.17-Release (1.12.18 kam am 2026-05-12), nicht der Tag. Ausgerechnet MVVM-Dateien belegen es — der Bereich, vor dem dieses Issue ohnehin warnt.

Folge für Schritt 3

Ein Graft auf v1.12.17 wäre falsch. Er würde jede künftige Zusammenführung auf eine erfundene Ahnenreihe stellen und Konflikte an Stellen erzeugen, wo keine sind — oder schlimmer: keine erzeugen, wo welche gehören. Wer den gemeinsamen Vorfahren nachträglich herstellen will, muss den passenden develop-Commit finden. Das braucht die volle Upstream-Historie; ein flacher Tag-Fetch reicht dafür nicht.

Schritt 3 bleibt damit offen, aber er hat jetzt eine tragfähige Fragestellung statt einer falschen Zielmarke.

Unverändert: die Advisory-Bewertung

Der Basisstand liegt zwischen 1.12.17 und 1.12.18 und damit klar unter 1.12.22 — GHSA-wrcp-5v3v-3j6v trifft uns weiterhin. Die Korrektur ändert die Dringlichkeit nicht, nur den Weg dorthin.

8.6 KiB Raw Blame History Unescape Escape