Vendoo 1.41.2 – Git Ignore Boundary & Module Tracking Hotfix (#18)

* docs: prepare Vendoo 1.41.2 git-ignore boundary hotfix

* fix: track native source modules with root-anchored runtime ignores

SECURITY.md

@@ -1,34 +1,151 @@
-# Sicherheitsrichtlinie
+## Source-Root- und Archivgrenzen ab 1.41.1
 
-Vendoo ist derzeit ein privates Projekt. Sicherheitsprobleme dürfen nicht als öffentliche GitHub-Issues mit Zugangsdaten, Tokens oder personenbezogenen Daten gemeldet werden.
+Historische Übergabe- und Featurepakete unter `Archiv/`, `archive/` oder `archives/` sind keine ausführbare Produktquelle. Sie werden aus Git-Staging, Release-Staging, Secret-Scan und ESM-Vertragsprüfung ausgeschlossen. Der produktive Source-Root bleibt separat vollständig geprüft; fehlende reale Moduldateien blockieren CI und Release.
 
-## Niemals committen
+# Sicherheit
 
-- `.env` und produktive Konfigurationsdateien
-- API-Schlüssel und OAuth-Tokens
-- SMTP-Zugangsdaten
-- Session-Secrets
-- SQLite-Datenbanken einschließlich WAL- und SHM-Dateien
-- Uploads, Backups und Logs
-- private Zertifikate und Schlüssel
+## Vertrauliche Dateien
 
-## Mindestanforderungen für Online-Betrieb
+Folgende Dateien dürfen niemals in Git oder öffentliche Pakete gelangen:
 
-- kein direktes Port-Forwarding auf Vendoo oder die NAS-Verwaltung
-- HTTPS über vorgeschalteten Reverse Proxy oder sicheren Tunnel
-- sichere Cookies (`HttpOnly`, `Secure`, `SameSite`)
-- korrekt begrenztes Express `trust proxy`
-- CSRF-Schutz für alle schreibenden Requests
-- Rollen- und Organisationsprüfung auf jeder geschützten Ressource
-- Rate-Limits für Login, Magic Links und sensible APIs
-- nicht privilegierter Container ohne Docker-Socket
-- persistente Daten ausschließlich in expliziten Vendoo-Volumes
-- automatische, geprüfte Backups
+- `.env`
+- `db/*.db`, `db/*.db-wal`, `db/*.db-shm`
+- `uploads/`
+- Backups, Logs und Session-Daten
+- private Schlüssel und Zertifikate
 
-## Geheimnisse
+## Online-Betrieb
 
-Produktive Geheimnisse werden über Server-Secrets beziehungsweise `_FILE`-Umgebungsvariablen bereitgestellt und nicht in der Datenbank oder im Repository im Klartext abgelegt.
+Vendoo darf nicht durch eine direkte Portfreigabe von Port 8124 veröffentlicht werden. Für öffentliche Nutzer ist eine getrennte Server-/VPS-Instanz hinter HTTPS und Reverse Proxy vorgesehen.
 
-## Abhängigkeiten
+## Meldung von Sicherheitsproblemen
 
-Vor Releases werden Abhängigkeiten, Container-Basisimages und bekannte Sicherheitslücken geprüft. Sicherheitsupdates erhalten Vorrang vor neuen Features.
+Sicherheitsprobleme nicht mit Zugangsdaten oder personenbezogenen Daten in öffentliche Issues schreiben.
+
+
+## Lokaler FLUX / ComfyUI
+
+- ComfyUI wird standardmäßig nur an `127.0.0.1` gebunden.
+- Vendoo blockiert Remote-ComfyUI-URLs, solange `LOCAL_IMAGE_ALLOW_REMOTE` nicht ausdrücklich aktiviert wird.
+- Die ComfyUI-Oberfläche wird nicht über das LAN veröffentlicht.
+- API-Aufrufe erfolgen serverseitig durch Vendoo.
+- Ein zufälliger Token wird für die lokale Integrationskonfiguration erzeugt.
+- Andere Prozesse auf demselben Windows-Rechner können theoretisch ebenfalls auf einen localhost-Dienst zugreifen; für echte Prozessisolation wäre ein separates Windows-Konto oder eine VM erforderlich.
+
+## ESM-Modulverträge ab 1.41.0
+
+- lokale benannte ESM-Imports werden vor CI und Release gegen die tatsächlich exportierten Symbole geprüft
+- fehlende Exporte blockieren den Build vor der Auslieferung
+- Worker-Start- und Stop-Verträge werden separat geprüft
+
+## FLUX Studio
+
+- ComfyUI bleibt standardmäßig ausschließlich an `127.0.0.1` gebunden.
+- Das FLUX Studio akzeptiert nur Textprompts und erzeugt Dateien unter `uploads/ai-generated`.
+- API-Pfade für Bibliothek und Bearbeitungen werden serverseitig auf dieses Verzeichnis begrenzt.
+- Start und Stopp der lokalen Engine erfordern eine Admin-Rolle.
+- Bearbeitungen erzeugen neue Dateien; Originalausgaben werden nicht still überschrieben.
+
+
+## Operations Center, Backups und Updates
+
+- Backups werden mit einem Manifest und SHA-256-Prüfsummen erzeugt und vor der Freigabe verifiziert.
+- Sicherungen, die `.env` enthalten, enthalten möglicherweise API-Schlüssel, Tokens und Zugangsdaten. Sie sind wie Passwörter zu behandeln und dürfen nicht unverschlüsselt weitergegeben werden.
+- Restore- und Update-Archive werden vor der Anwendung in einem lokalen Staging-Bereich geprüft.
+- Archive mit Pfad-Traversal, absoluten Pfaden oder unzulässigen Laufzeitdaten werden abgewiesen.
+- Updates dürfen keine `.env`, produktive Datenbank, Uploads, Backups, Logs, Modelle oder `node_modules` mitbringen.
+- Das eigentliche Anwenden erfolgt nur bei gestopptem Vendoo über `setup.bat` und erzeugt vorher einen Rollback-Snapshot.
+- Eine optionale Update-Manifest-URL sollte ausschließlich über HTTPS und aus einer kontrollierten Quelle verwendet werden.
+- Extension-Heartbeats enthalten nur Diagnosemetadaten wie Browser, Version, Plattform und Zeitpunkt; keine Formularinhalte oder Zugangsdaten.
+## Mehrbenutzer- und Server-Sicherheit ab 1.31.0
+
+- Vendoo bindet standardmäßig an `127.0.0.1`. LAN-Zugriff muss ausdrücklich über `VENDOO_BIND_HOST=0.0.0.0` aktiviert werden.
+- Öffentlicher Betrieb ausschließlich über HTTPS und einen korrekt konfigurierten Reverse Proxy. `VENDOO_TRUST_PROXY=true` nur setzen, wenn der Proxy vertrauenswürdig ist und Client-IP-Header kontrolliert.
+- `VENDOO_ALLOWED_HOSTS` und `VENDOO_ALLOWED_ORIGINS` eng begrenzen.
+- Rollen ersetzen keine Betriebssystemrechte: Datenbank, `.env`, Backups und Uploads müssen auf Dateisystemebene geschützt bleiben.
+- Bearbeitungssperren verhindern parallele Änderungen, ersetzen aber keine Backups.
+- Audit-Logs können personenbezogene Betriebsdaten wie Benutzer, IP und Aktionen enthalten; Aufbewahrung und Zugriff müssen organisatorisch geregelt werden.
+
+
+
+## Architektur-Sicherheitsregeln ab 1.35.0
+
+- Neue Kernel-Routen sind Deny-by-default und benötigen eine registrierte Policy.
+- Modulmanifeste, Abhängigkeiten, Capabilities und Ownership werden vor dem Start validiert.
+- Zyklische Abhängigkeiten, fehlende Capabilities und doppelte Ressourcen-Ownership blockieren den Kernelstart.
+- Drittanbieter-Erweiterungen dürfen nicht im Vendoo-Hauptprozess ausgeführt werden.
+- Themes dürfen nur freigegebene, typisierte Design Tokens verändern; freies CSS, JavaScript und externe URLs sind verboten.
+- Der Event Bus ordnet Listener einem Owner zu, damit Module beim Stoppen ihre Listener vollständig entfernen können.
+- Das Architektur-Gate `npm run verify:architecture` ist verpflichtender Bestandteil von CI und Releases.
+
+## Theme-Sicherheit ab 1.36.0
+
+- Theme-Profile akzeptieren ausschließlich bekannte, typisierte Design Tokens.
+- Freies CSS, JavaScript, HTML, URLs und Dateipfade sind nicht zulässig.
+- Alle Werte werden im Browser zur Benutzerführung und erneut auf dem Server validiert.
+- Normale Benutzer können nur die eigene Theme-Präferenz verändern.
+- Theme-Profile und Systemstandard erfordern `settings.manage`.
+- Theme-Änderungen werden auditiert.
+- Importierte Profile durchlaufen dieselbe Validierung wie manuell erstellte Profile.
+- Kontrastprüfungen verhindern nicht automatisch jede bewusste administrative Gestaltung, zeigen problematische Paare aber vor dem Speichern deutlich an.
+
+
+
+## Security Foundation ab 1.37.0
+
+Zugangsdaten werden bevorzugt im verschlüsselten Secret-Speicher unter dem persistenten Konfigurationsbereich abgelegt. Die Verschlüsselung verwendet AES-256-GCM; der Master-Key liegt getrennt und wird nicht in Git oder Release-Pakete aufgenommen. Bestehende Secrets aus der Runtime-Konfiguration werden beim ersten Start gesichert, verschlüsselt migriert und aus der Klartextdatei entfernt.
+
+Die Weboberfläche verwendet eine erzwungene Content Security Policy ohne Inline-Skripte und Inline-Eventhandler. Request- und Correlation-IDs werden in Antworten ausgegeben und in der strukturierten Telemetrie geführt.
+
+## Identity- und Settings-Sicherheit ab 1.38.0
+
+- Auth, Benutzer, Sitzungen und Einstellungen laufen als native Module über explizite Policies und Eingabeschemata.
+- Der letzte aktive Administrator kann nicht gelöscht, deaktiviert oder zu einer Nicht-Admin-Rolle herabgestuft werden.
+- Benutzer können nur Sitzungen widerrufen, die ihrer eigenen Benutzer-ID gehören; administrative globale Revocation erfordert `sessions.manage`.
+- Login-Historie erfordert `users.manage`, SMTP-Verwaltung `settings.manage`.
+- Die Settings-Allowlist weist unbekannte oder nicht freigegebene Felder zurück.
+- Passwort-Hashes, Session-Tokens und Secret-Klarwerte dürfen nicht in Listen-, Status- oder Audit-Antworten erscheinen.
+- `lib/auth.mjs` ist nur noch eine Kompatibilitätsfassade; neue Identitätslogik gehört in die nativen Module.
+
+## Catalog- und Medien-Sicherheit ab 1.39.0
+
+- Artikelrouten verwenden explizite Policies für Lesen, Bearbeiten, Papierkorb und endgültiges Löschen.
+- Unbekannte Artikel-, Lager- und Medienfelder werden abgewiesen.
+- Rich-HTML wird serverseitig bereinigt; Preise, Texte, Tags und Fotolisten besitzen feste Grenzen.
+- Endgültiges Löschen ist nur für bereits im Papierkorb befindliche Artikel möglich.
+- Lager-Bulk-Aktionen sind auf 500 eindeutige positive Artikel-IDs begrenzt.
+- Medienpfade werden normalisiert und gegen Traversal, Nullbytes sowie Zeilenumbrüche geprüft.
+- Von aktiven Artikeln referenzierte Bilder sind beim Löschen geschützt.
+- Modulimporte initialisieren keine Datenbank; Repositories werden beim Serverstart injiziert.
+
+
+## Modulsicherheit ab 1.40.0
+
+- Kernmodule sind geschützt und können weder deaktiviert noch gelöscht werden.
+- Aktivierungszustände werden atomar im persistenten Konfigurationsbereich gespeichert.
+- `.vmod`-Pakete werden auf Format, Manifest, Pfade, Dateigrößen, Einzeldatei-SHA-256 und Gesamtintegrität geprüft.
+- Installierbare Fremdmodule müssen den Typ `extension-host` verwenden.
+- Deklarative Pakete dürfen keine JavaScript-, Shell-, Native- oder Binärdateien enthalten.
+- Ausführbare Pakete benötigen eine vertrauenswürdige Ed25519-Signatur und dürfen ausschließlich in einem isolierten Extension-Host laufen. Solange dieser Host nicht freigegeben ist, bleiben solche Pakete deaktiviert und quarantänisiert.
+- Fremdmodule werden niemals durch bloßes Kopieren automatisch registriert oder aktiviert.
+- Abhängigkeiten werden vor Aktivierung geprüft; geschützte Abhängigkeiten verhindern unsichere Deaktivierung.
+- Installierte Modulpakete und `modules-state.json` werden gemeinsam gesichert und wiederhergestellt.
+- Der Laufzeitordner `modules/` ist von Git-Import und Release-Paketen ausgeschlossen.
+
+## Produktionsdeployments über Coolify (1.41.0)
+
+- der Vendoo-Container erhält keinen Zugriff auf `/var/run/docker.sock`
+- Vendoo verändert seinen eigenen Container nicht und führt kein `git pull` aus
+- Coolify-API-Token und Deploy-Webhook liegen ausschließlich im verschlüsselten Secret Store
+- Deploymentrouten benötigen `updates.manage`, CSRF-Schutz, Rate Limit und Audit
+- ein Deployment erfordert die exakte Bestätigung `DEPLOY`
+- standardmäßig wird vor jedem Auftrag ein Backup einschließlich Konfiguration erzeugt
+- Produktionsendpunkte müssen HTTPS verwenden
+- Antworten externer Deploymentdienste werden begrenzt und Redirects nicht automatisch verfolgt
+- der Initialwert für deaktivierte Module überschreibt keine spätere persistente Administratorentscheidung
+
+
+
+## Git-Ignore-Grenzen
+
+Lokale Runtimeordner werden ausschließlich als Root-Pfade (`/modules/`, `/sessions/`, `/logs/` usw.) ignoriert. Produktive Quellpfade unter `app/modules/` dürfen weder ignoriert noch ungetrackt sein; CI und Deploy-Assistent erzwingen diese Grenze.