Files

T

Thore CimbalandClaude Opus 5 667f69d93f chore(issues): record the mirror addresses from the first full run

The mirror created the seven issues that had never reached the board
(management#33-39) and wrote each new iid back into its file. Without the
writeback the next run would create duplicates instead of recognising its own
work.

Group check after the run: the issue drift class is empty - 27 findings down to
20, 7 hints to 0, and not a single GitLab issue without a canonical file. What
remains is unrelated to the board: seventeen commit-hygiene findings parked in
#0053 and three component declarations.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-18 12:00:00 +00:00

4.5 KiB

Raw Blame History

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

type

status

created

milestone

priority

area

gitlab_iid

issue

0055

open

2026-08-16

medium

security

docs/issues/0054-ki-geraeuschunterdrueckung-element-call.md

docs/adr/0018-ki-geraeuschunterdrueckung-clientseitig-opt-in.md

docs/adr/0001-gitlab-kanonisch-push-mirror.md

Issue-0055: `@sorb`-Scope in ThreadNet-Web ist nirgends auf rohana festgelegt

Problem / Motivation

ThreadNet-Web bezieht @sorb/threadnet-call-embedded aus der Gitea-npm-Registry auf rohana, aber im Repo steht nirgends, dass der Scope @sorb dorthin zeigt. Es gibt weder eine .npmrc im Wurzelverzeichnis noch in apps/web, und die CI setzt auch keine.

Dass es trotzdem funktioniert, liegt allein am Lockfile: pnpm-lock.yaml pinnt die vollständige Tarball-URL

tarball: https://rohana.axion1337.de/api/packages/sorb/npm/%40sorb%2F…tgz

und die CI installiert mit --frozen-lockfile. Solange niemand die Version anhebt, wird der Scope nie aufgelöst — und der fehlende Eintrag fällt nicht auf.

Aufgefallen beim Anheben auf 0.19.2-threadnet.8 (#0054): pnpm install griff nach registry.npmjs.org und brach ab.

ERR_PNPM_FETCH_404  GET https://registry.npmjs.org/@sorb%2Fthreadnet-call-embedded: Not Found

Die Anhebung ging nur durch, weil der Scope für diesen einen Aufruf von Hand gesetzt wurde:

env 'npm_config_@sorb:registry=https://rohana.axion1337.de/api/packages/sorb/npm/' pnpm install

Das steht in keiner Doku. Der nächste, der die Abhängigkeit anhebt, läuft in dieselbe Wand.

Warum das mehr ist als eine Unbequemlichkeit

Der heutige Fehlschlag ist laut — 404, Abbruch, niemand baut versehentlich etwas Falsches. Laut ist gut. Der Punkt ist, dass die Lautstärke von einer Bedingung abhängt, die uns nicht gehört: @sorb/threadnet-call-embedded existiert auf registry.npmjs.org derzeit nicht.

Registriert dort jemand diesen Namen, löst genau derselbe Befehl nicht mehr mit 404 auf, sondern erfolgreich — gegen ein fremdes Paket. Das ist das Muster, das als dependency confusion bekannt ist, und die Bedingung dafür ist nicht „ein Angriff auf uns", sondern „jemand legt einen Scope-Namen an". Der Schutz besteht heute ausschließlich darin, dass ein Name auf einer fremden Registry noch frei ist.

Verschärfend: Der Fehler träfe genau den Moment, in dem jemand eine Version anhebt — also den Moment, in dem eine neue Abhängigkeit ohnehin erwartet wird und ein Download nicht auffällt.

Das ist dieselbe Klasse wie die Befunde aus #0054 und der Backup-Reihe: die Absicherung besteht nicht, sie ergibt sich nur zufällig aus dem aktuellen Zustand. Sie „meldet" auch nichts — sie funktioniert stillschweigend, bis sie es nicht mehr tut.

Acceptance

Eine eingecheckte .npmrc in ThreadNet-Web bindet den Scope fest: @sorb:registry=https://rohana.axion1337.de/api/packages/sorb/npm/
Ein Anheben der Version funktioniert im frischen Klon ohne Zusatzschritte — das ist der eigentliche Nachweis, nicht das Vorhandensein der Datei.
Gegenprobe: Ein Lauf mit absichtlich unerreichbarer rohana scheitert, statt auf registry.npmjs.org auszuweichen.
Die anderen Repos der Gruppe sind auf denselben Befund geprüft: Wer sonst noch @sorb-Pakete zieht, hat dieselbe Lücke (threadnet-call selbst publisht nur, konsumiert aber ggf. auch).
Der Auslieferungsweg in ThreadNet-Web:docs/axion1337-fork.md nennt den Befehl zum Anheben.

Notes

Kein Token nötig. Der Lesezugriff auf die Registry ist anonym möglich (nachgeprüft: der Paket-Index antwortet ohne Authentifizierung). Die .npmrc enthält damit nur eine URL und kein Geheimnis und kann bedenkenlos eingecheckt werden — das ist der Grund, warum hier kein Secrets-Handling dranhängt.

Warum nicht einfach dokumentieren: Ein Satz in der Fork-Doku würde den 404 erklären, aber die registry.npmjs.org-Auflösung nicht verhindern. Nach der Lehre aus #0053 und dem Bindmount-Fall ist Aufschreiben hier ausdrücklich nicht die Maßnahme: die Regel war beide Male vorhanden und hat den Fehler nicht verhindert. Wirksam ist die eingecheckte Datei, weil sie den falschen Weg gar nicht erst offen lässt.

Verwandt, aber getrennt: Bei der Gelegenheit ist aufgefallen, dass der Job publish_npm in threadnet-call allow_failure: true trägt — ein scheiternder Publish färbt die Pipeline nicht rot. Das ist ein eigener Befund und gehört nicht in dieses Issue; hier nur notiert, damit er nicht verloren geht.

4.5 KiB Raw Blame History

Issue-0055: @sorb-Scope in ThreadNet-Web ist nirgends auf rohana festgelegt