Files

T

Thore CimbalandClaude Opus 4.8 78228e4d3b docs(issues): #0055 — the @sorb scope is pinned nowhere but the lockfile

ThreadNet-Web resolves @sorb/threadnet-call-embedded from rohana only because
pnpm-lock.yaml pins the full tarball URL and CI installs frozen. There is no
.npmrc anywhere, so the moment someone bumps the version, pnpm reaches for
registry.npmjs.org instead. Hit while bumping to .8 for #0054.

Today that fails loudly with a 404 — but only because the name happens to be
unregistered on public npm. The protection is a coincidence, not a control:
register that name and the same command resolves successfully against a
stranger's package, in the one moment where a fresh download looks expected.

Documenting it is explicitly not the fix here; the checked-in .npmrc is, because
it removes the wrong path rather than warning about it.

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

2026-08-16 12:00:00 +00:00

4.4 KiB

Raw Blame History

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

type

status

created

milestone

priority

area

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.4 KiB Raw Blame History

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