Commit Graph
4 Commits
Author SHA1 Message Date
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
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
Thore Cimbal 5297104846 docs(issues): #0099 - measured, and the answer is neither panic nor precaution
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.
2026-08-19 12:00:00 +00:00
Thore CimbalandClaude Opus 5 a1def8666e feat(issues): adopt the component trackers — one backlog, one numbering (ADR-0019)
ADR-0012 made docs/issues/ canonical for the management scope only and left
gitops, ThreadNet-Web and threadnet-call on GitLab "until the component adopts".
That split produced exactly what it invited: two numbering worlds where
management#20 and gitops#20 are different issues, drift nobody had to answer for
(gitops#61 carried no milestone since 2026-08-11), and component backlogs that
host sessions without lab access cannot read at all.

The 46 open component issues are now files 0056-0101. The file id is the
group-wide identifier; provenance lives in the frontmatter (new field `projekt`
plus gitlab_iid) and in the filename, so "gitops#61" still finds 0091. Bodies are
copied verbatim; comments and history stay on GitLab, as with the 2026-08-11
management import.

Both scripts learned the second dimension: spiegel_issues.py routes each file to
its origin project, reopens issues that are open in the repo but closed on the
board, and writes the new iid back after creating one; gruppenpruefung.py checks
drift across all four trackers instead of management alone. What the mirror
cannot decide stays a finding, not a silent state.

Two things needed a hand, both recorded in the files: gitops#61 had no milestone
(M1 - it is a live account-takeover path) and carried two area labels where the
schema holds one. The Gitea migration footers in the imported bodies point at
decommissioned trackers; their links are removed, the provenance sentence stays.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 12:00:00 +00:00