docs(backlog): security-triage 2026-07-28 — die sieben Aufräum-Items

[MoltyCel]

Backlog-Nachtrag zur Triage der drei Alerts aus dem security_check.sh-Lauf vom 2026-07-26. Nur docs/BACKLOG.md, kein Code.

Erledigt und deployt (nicht Teil dieses PRs)

Fund	Status
mcp 1.26.0 → 1.28.1 (GHSA-jpw9-pfvf-9f58, HIGH, erreichbarer Transport)	moltrust-mcp-server #14, gemergt + deployt
MoltGuard 6 high → 0 (npm audit fix, non-major)	moltguard #10, gemergt + deployt
Port 3006 „unexpected open"	Fehlalarm, keine Regression — MoltProof bindet auf 127.0.0.1, extern gefiltert

Was hier ins Backlog geht

Sieben Items, keines davon ein erreichbarer Pfad, jedes ein Struktur- oder Hygieneproblem, das ein Versions-Bump nicht löst:

1. pypdf streichen statt hochziehen — 4 Advisories (2 HIGH), aber nirgends importiert, Required-by leer
2. liboqs-Pin klären — requirements.txt pinnt 0.15.0, die Prod-venv kennt das Paket nicht; der Pin ist wirkungslos und pip-audit kann dazu gar nichts sagen
3. email → EmailStr (app/main.py:1219) — der aiosmtplib-CR/LF-Fund läuft heute nur deshalb ins Leere, weil die stdlib beim Serialisieren HeaderParseError wirft (auf Python 3.12.3 geprüft). Die Validierung fehlt trotzdem und hängt an fremdem Verhalten
4. aiosmtplib, mcp, moltrust-mcp-server in requirements.txt deklarieren — alle drei laufen, keiner steht drin; ein pip install -r requirements.txt auf frischer Maschine brächte den MCP-Server nicht mit
5. Port-Check reparieren (scripts/security_check.sh Z. ~186) — grep -oP ':\K[0-9]+$' verwirft die Bind-Adresse, 127.0.0.1:3006 und 0.0.0.0:3006 sind für den Check identisch. Daher der Fehlalarm. Konkreter Kandidat, den er danach fangen würde: 8168 (moltrust-uresolver.service) bindet auf *:8168
6. ruff in moltrust-mcp-server/.github/workflows/ci.yml pinnen — pip install ruff ohne Pin; ruff 0.16.0 hat ci: initial GitHub Actions workflow (install + syntax + pytest collect) #14 rot gemacht, mit einem I001 auf eine Datei, die der PR nicht angefasst hatte
7. Report-Abschnitt 1e — DID-Core-Link veraltet (/TR/did-core/ → /TR/did-1.0/), und 1e prüft nichts, es druckt zwei URLs und einen Merksatz

Abweichung von der Vorlage

Punkt 7 war als „kaputte W3C-Markdown-Links" notiert. Das ließ sich nicht belegen: 1e schreibt nackte URLs in einen Plaintext-Report, beide antworten 200. Der Telegram-Pfad sendet zwar mit parse_mode="HTML", überträgt aber nur das ALERTS-Array und nie den Reportkörper — 1e läuft dort gar nicht durch, die Mail geht als MIMEText(body, 'plain') raus. Im Eintrag steht deshalb nur, was geprüft ist: der veraltete Verweis und die fehlende Mechanik.

🤖 Generated with Claude Code

[MoltyCel]

Zweiter Commit: der liboqs-Pin ist raus — er hatte die CI des ganzen Repos rot gemacht

Beim ersten Push fielen beide pytest-Jobs um, auf einem PR, der nur docs/BACKLOG.md anfasste:

ERROR: Could not find a version that satisfies the requirement
       liboqs-python==0.15.0 (from versions: 0.16.0)
ERROR: No matching distribution found for liboqs-python==0.15.0

liboqs-python 0.15.0 ist von PyPI verschwunden — das Projekt serviert nur noch 0.16.0, /pypi/liboqs-python/0.15.0/json gibt 404. Damit scheitert pip install -r requirements.txt, und jeder PR im Repo lief rot, unabhängig vom Inhalt. Letzter grüner Lauf auf main war 93ac358.

Gestrichen, nicht auf 0.16.0 gehoben. Das entspricht dem Ist-Zustand:

Prod-venv	hat das Paket nie gehabt
is_available() in app/crypto/dilithium.py	liest dort False
DILITHIUM_*-Variablen	keine gesetzt
import oqs	liegt innerhalb der Funktionen, Degradation ist gewollt

Ein Bump hätte bei jedem frischen Install eine PQC-Bibliothek hereingezogen, die kein Codepfad aufruft.

Die Begründung des ursprünglichen Hard-Pins bleibt als Kommentar an der Fundstelle stehen, ausdrücklich mit der Bitte, ihn nicht blind wieder einzusetzen. Der Supply-Chain-Einwand gegen ein pre-1.0, nicht FIPS-validiertes C-Binding (3-Modell-Review-Konsens, Gemini + Perplexity) gilt weiter — er ist nur nicht mit == gegen ein Projekt lösbar, das seine Releases zurückzieht. Die Historie im Kommentar zeigt das Muster: 0.10.2 wurde vom Review zitiert und existierte nie, dann waren 0.14.1/0.15.0 die realen (verifiziert 2026-07-03), und jetzt ist 0.15.0 ebenfalls weg.

Wieder deklarieren, wenn PQC scharf geht: gepinnt, gegen das dann existierende Release, und mit im Deploy verifizierter Installation statt angenommener.

Verifiziert: pip install --dry-run -r requirements.txt in einer frischen venv auf Python 3.12.3 — der Version, die die CI fährt — löst vollständig auf, rc=0.

Nebenbefund aus derselben Auflösung: ein frischer Install zöge pypdf-6.14.2, also die gepatchte Fassung. Die Prod-venv steht auf 6.13.3, weil sie älter installiert wurde. Ändert nichts am Backlog-Item, pypdf gehört gestrichen statt hochgezogen — es wird nirgends importiert.