Thore Cimbal
8c07c365f6
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.
163 lines
8.6 KiB
Markdown
163 lines
8.6 KiB
Markdown
---
|
||
type: issue
|
||
id: "0099"
|
||
status: open
|
||
created: 2026-08-06
|
||
milestone: M1
|
||
priority: medium
|
||
projekt: threadnet-web
|
||
gitlab_iid: "12"
|
||
related: []
|
||
---
|
||
# Upstream-Sicherheitsfixes lassen sich nicht mergen — kein gemeinsamer Vorfahre
|
||
|
||
> Adoptiert aus [threadnet-web#12](https://git.lab/axion1337.chat/ThreadNet-Web/-/issues/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
|
||
|
||
1. **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.
|
||
2. `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.
|
||
3. 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.
|
||
4. 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](../adr/0021-foederation-geschlossen.md) 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.
|