stwaidele/dorfteich
1
0
Fork 0
Code Issues 2 Pull Requests Actions Packages Projects Releases 22 Wiki Activity
d76c731473
dorfteich/docs/vs-nfd/90-restrisiken.md
Claude Fable 5 9b7acab294
All checks were successful
CI / Lint, typecheck, test (pull_request) Successful in 6m21s
Details
CI / Build container images (pull_request) Successful in 3m59s
Details
CI / Auth e2e pack (pull_request) Successful in 8m35s
Details
CI / Import/export fidelity gate (pull_request) Successful in 1m1s
Details
CD / Build and push images (push) Successful in 17s
Details
CD / Deploy to Test (push) Successful in 14s
Details
CD / Smoke tests against Test (push) Successful in 1m17s
Details
CD / Promote to Int (push) Successful in 12s
Details
CI / Build container images (push) Has been skipped
Details
CI / Auth e2e pack (push) Successful in 8m27s
Details
CI / Import/export fidelity gate (push) Successful in 58s
Details
CI / Lint, typecheck, test (push) Successful in 6m30s
Details
#232: plugin allowlist with SHA-256 hash pinning 
The install path records the SHA-256 of the delivered bundle ZIP
(plugins.bundle_hash; pre-#232 installs show it as unknown until
reinstalled). plugins.allowlist in instance_settings names permitted
ids with their pinned hashes: empty (default) = not enforced, existing
instances unchanged; non-empty = installs of unlisted or deviating
bundles are rejected (plugin_not_pinned / plugin_hash_mismatch, 403),
and an installed plugin outside the list or with a deviating hash does
not load — absent from pond mount lists, frame/assets 404. Every
rejection is audited (plugin.rejected, catalogue v1.5). A version bump
changes the hash and therefore requires an explicit re-pin — the
intended friction (ADR 0025). Admin UI shows observed vs pinned hash
per plugin with pin/re-pin/unpin. Scope stated honestly in
plugin-architecture.md: the pin answers "is this the reviewed bundle";
post-install disk tampering is platform integrity (ADR 0019), sandbox
containment stays the sandbox's job. Hardening guide row + catalog
advisory triage; residual risk R-03 resolved. e2e: empty-allowlist
compatibility, pinned load, unpinned and tampered installs rejected and
audited, pin drift blocks loading while the admin still sees the
mismatch, version bump needs re-pin. Full api suite 101 files / 561
green.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AUtYMxwTCMHG9mVHnwbFg8
2026-07-31 21:26:36 +02:00

8.3 KiB
Raw Blame History

Restrisikoliste (VS-NfD, Issue #231)

Zweck: benennen, was bewusst offen bleibt. Ein Prüfer, der eine Lücke hier bereits verzeichnet findet, kann ihr zustimmen; eine unverzeichnete Lücke diskreditiert die gesamte Einreichung. Jeder Eintrag nennt das Risiko, warum es akzeptiert ist, die kompensierende Kontrolle und wer entschieden hat.

Pflegeregel (verbindlich): Schließt ein Issue mit einem wissentlich offenen Rest, wird diese Liste im selben PR ergänzt. Die formale Billigung der Einträge durch den jeweiligen Betreiber ist Teil seiner Risikoübernahme (Abgrenzungserklärung §8) — Bewertung/Scoring ist bewusst nicht Teil dieser Liste.

Entscheidungsvermerk: „Projektleitung" = Stefan Waidele; Entscheidungen sind über die genannten PRs/Issues/ADRs im Repository nachvollziehbar.

R-01 Attachment-Inhalt trägt keine interne Kennzeichnung

  • Risiko: Eine heruntergeladene, umbenannte Datei (bzw. eine ohne Begleitdatei weitergegebene) ist ein eingestuftes Binärobjekt ohne sichtbare Kennzeichnung.
  • Warum akzeptiert: Kennzeichnung in beliebige Binärformate zu schreiben hieße, fremde Formate umzuschreiben — ausgeschlossen durch ADR 0019/0022 (keine Übernahme von Grundfunktions-/Formatgarantien).
  • Kompensation: Download-Präfix VS-NfD_ + Begleitdatei/Manifest im ZIP (#212); alle internen Darstellungen und alle übrigen Exportkanäle kennzeichnen selbst (#206–#211); Upload-Warnung bzw. serverseitiger Block (#213); organisatorische VS-Handhabung beim Empfänger.
  • Entscheidung: Projektleitung, PR #271 / Issue #212, 31.07.2026.

R-02 Lokale Passwort-Authentifizierung noch nicht abschaltbar — ERLEDIGT (#216, 31.07.2026)

  • Status: geschlossen. Der harte Schalter existiert als Deploy-Variable AUTH_LOCAL_ENABLED=false (#214–#216, ADR 0021): jeder lokale Credential-Flow (Login, Signup, Verifikation, Passwort vergessen/zurücksetzen/ändern) antwortet 404; Anmeldung läuft über OIDC (#214) bzw. Perimeter-Auth (#215). Die im Risiko offene Frage „Laufzeit oder Deploy-Ebene" ist zugunsten der Deploy-Ebene entschieden — ein kompromittierter Site-Admin kann den lokalen Pfad nicht wieder öffnen; damit entsteht KEIN Laufzeit-Restrisiko. Verbleibender Hinweis (dokumentiert, ADR 0021): bestehende Argon2id-Passwort-Hashes bleiben nach dem Umschalten in der Datenbank stehen; ihre Löschung ist bewusst nicht Teil von #216.
  • Entscheidung: Projektleitung, Issue #216, 31.07.2026 (ursprüngliche Aufnahme: Maßnahmenplan Rev. 2, 30.07.2026).

R-03 Plugin-Hash-Pinning verschoben — AUFGELÖST (31.07.2026, #232)

  • Ursprüngliches Risiko: Installierte Plugin-Pakete waren nicht gegen einen festgeschriebenen Hash verankert; ein manipuliertes Paket gleichen Namens wäre beim Neuinstallieren nicht erkennbar gewesen.
  • Auflösung: Hash-Pinning ist mit #232 umgesetzt (ADR 0025): SHA-256-Erfassung beim Install, Allowlist plugins.allowlist (id + gepinnter Hash), Durchsetzung bei Install UND Load (fail-closed, Abweisungen auditiert plugin.rejected), Versionswechsel nur per explizitem Re-Pin. Die Referenzkonfiguration betreibt Plugins weiterhin gar nicht (plugins.enabled=false); für abweichende Betreiber ist das Pinning jetzt verfügbar statt zurückgestellt.
  • Verbleibender Hinweis (dokumentiert): Der gesehene Hash wird beim Install erfasst; nachträgliche Manipulation entpackter Dateien auf der Platte ist Plattform-Integrität (ADR 0019), nicht Gegenstand der Prüfung. Vor #232 installierte Plugins tragen bis zur Neuinstallation keinen erfassten Hash.
  • Entscheidung: Projektleitung, ADR 0025 / Issue #232; aufgelöst 31.07.2026 (ursprüngliche Aufnahme 30.07.2026).

R-04 Git-Historie: einmalige Secret-Prüfung mit begrenztem Muster

  • Risiko: Die einmalige Prüfung der gesamten Repository-Historie (#198, 30.07.2026) fand keine getrackten .env-Dateien und keine Treffer der Muster Private-Key-Block / AKIA / ghp_ / glpat- / xox[baprs]-. Unstrukturierte Passwörter als schlichte Strings würde ein generisches Muster jedoch nicht finden.
  • Warum akzeptiert: Ein Negativbeweis über beliebige Strings ist nicht führbar; das strukturierte Muster deckt die realistischen Token-Formate.
  • Kompensation: CI-Zaun „No tracked .env files or secret material" auf jedem PR (#198) hält beide Invarianten ab jetzt; Review-Disziplin
    • Regel „Passwörter nie als CLI-Argument/Commit".
  • Entscheidung: Projektleitung, Issue #198, 30.07.2026 (Protokoll als Kommentar auf #231).

R-05 Digest-/Benachrichtigungs-Mails tragen Seitentitel (I-23)

  • Risiko: Zugestellte Mails enthalten Titel (Inhalts-Metadaten) eingestufter Seiten und liegen beim Empfänger außerhalb der Instanz.
  • Warum akzeptiert: Es gab bis M26 kein Einstufungs-Metadatum für eine Unterdrückung; die titelbasierte Unterdrückung wird in M32 (#243–#246, VS_NFD_MODE) revisitiert.
  • Kompensation: Kopie zeitlich begrenzt (mail.outboxRetentionDays, #234); Referenzkonfiguration lässt SMTP unkonfiguriert — dann verlässt kein Titel die Instanz per Mail (50-haertungsleitfaden.md §1.2).
  • Entscheidung: Projektleitung, PR #255 / Issue #234, 30.07.2026; Revisit-Marker M32.

R-06 page_links.target_slug überlebt den Ziel-Purge (I-24)

  • Risiko: Nach dem endgültigen Löschen einer Seite bleibt ihr Slug (≈ Titel) als Linkziel-Text in den Zeilen verweisender Seiten.
  • Warum akzeptiert: Der Slug steht ohnehin sichtbar im Inhalt der verweisenden Seite (deren Autor das Ziel lesen durfte); die Zeile zu löschen entfernte nichts Sichtbares, bräche aber die gewollte Phantom-Link-Reauflösung.
  • Kompensation: Zugriff auf die verweisende Seite bleibt permissions-geprüft; vollständige Begründung in docs/architecture/operations.md (Purge-Abschnitt).
  • Entscheidung: Projektleitung, PR #256 / Issue #235, 30.07.2026.

R-07 Offline-Kopie im Browser (IndexedDB, I-25)

  • Risiko: Der Editor hält zuletzt geöffnete Seiten als Yjs-Offline-Kopie in der IndexedDB des Endgeräts (apps/web/src/editor/use-collab-provider.ts); sie übersteht Browser-Crashes und existiert für unsynchronisierte Offline-Edits.
  • Warum akzeptiert: Die Kopie ist Voraussetzung für verlustfreies kollaboratives Arbeiten (CRDT) und liegt in der Endgeräte-Zone, deren Schutz (Festplattenverschlüsselung, Gerätekontrolle) nach Abgrenzungserklärung ohnehin der Plattform- bzw. Organisationsverantwortung zufällt.
  • Kompensation: VS-Endgeräte-Vorgaben des Betreibers (Datenträgerverschlüsselung, kontrollierte Geräte); kurze Sessions (Referenzkonfiguration) begrenzen den angemeldeten Zeitraum.
  • Entscheidung: Projektleitung, Ist-Aufnahme I-25 (10-ist-aufnahme.md), 29.07.2026.

R-08 Bewusst nicht geplante Funktionen

  • Risiko/Inhalt: Externe Suchengine (Suche bleibt in Postgres), Admin-Freigabe von Selbstregistrierungen, Plugin-Netzwerk-Allowlist — bewusst unscheduled.
  • Warum akzeptiert: Kein Bedarf im Zielbetrieb: die Referenzkonfiguration schließt Selbstregistrierung und Plugins ohnehin aus; die interne Suche vermeidet einen weiteren Dienst mit Inhaltskopie (die Kopienliste bliebe sonst nicht klein).
  • Kompensation: entfällt (kein zusätzliches Risiko gegenüber dem Status quo; Wiedervorlage bei realem Bedarf).
  • Entscheidung: Projektleitung, Projektplanung (dokumentiert im Workspace-Handoff), Stand 07/2026.

R-09 Site-Admin liest jeden Inhalt (Rollen-Bypass)

  • Risiko: Die App-Rolle Site-Admin umgeht die Permission-Resolution vollständig (permissions.md) — App-seitig gibt es keine absolute Trennung zwischen Plattform-Betrieb und Inhalts-Kenntnisnahme.
  • Warum akzeptiert: Ein Admin ohne Durchgriff könnte zentrale Pflichten (Purge, Quoten, Störungsanalyse) nicht erfüllen; eine echte Trennung wäre eine neue Grundfunktion (ADR 0019).
  • Kompensation: organisatorisch (Vergabe der Rolle nach Need-to-know, Vier-Augen-Prinzip); Lesetrail für eingestufte Inhalte macht Zugriffe nachvollziehbar (M29, #222–#225 — bis dahin trägt der bestehende Audit-Trail nur Verwaltungsereignisse); Betriebshandbuch §6 benennt die Grenze ausdrücklich.
  • Entscheidung: Projektleitung, permissions.md-Design (Issue #51) bzw. Aufnahme hier, 31.07.2026.