2 Commits

Include renames

Author	SHA1	Message	Date
Deploymentcenter BotandClaude Opus 5	7a3a5dad69	fix(releases): Lizenzschluessel nicht mehr im Klartext, Selbsttest, Zielorte ... Vier Befunde aus einer externen Durchsicht der 2.4-Integration. 1. Die .htpasswd war eine Klartext-Kundenliste Das htpasswd-Format hasht nur die Passwortspalte. Benutzername UND Passwort waren der Lizenzschluessel - der Schluessel stand also im Klartext direkt neben seinem eigenen bcrypt-Hash, und der Hash war Dekoration. Geschuetzt hat das Ganze nur die FilesMatch-Regel in derselben Datei. Der Benutzername wird jetzt abgeleitet: lic_<sha256(schluessel), 16 Hex>. Die Datei enthaelt damit nur noch eine Einwegableitung und einen Hash ueber einen hochentropen Schluessel. Server und SDK muessen dabei zeichengenau uebereinstimmen; ein Test prueft die C#-Ableitung gegen die PHP-Formel. 2. Ein Formatwechsel blieb unbemerkt liegen Beim Umbau auf 1. faellt auf: reconcile() sah keinen Anlass zur Neuerzeugung, die Dateien behielten das alte Format, waehrend die Clients bereits das neue schickten. Die erzeugten Dateien tragen deshalb jetzt eine Formatkennung; weicht sie ab, wird neu erzeugt. 3. Doku beschrieb Nginx, der Schutz ist Apache-only .htaccess wird von Nginx ignoriert - dort waeren die Verzeichnisse offen und die .htpasswd oeffentlich abrufbar. Die Statusanzeige pruefte nur, ob die Dateien existieren, und haette in dem Fall "GESCHUETZT" gemeldet. Neu: ein echter Selbsttest ruft die eigene Paket-Adresse OHNE Zugangsdaten ab und erwartet 401. Er laeuft beim manuellen Erzeugen und nach jeder automatischen Neuerzeugung; das Ergebnis steht in der Oberflaeche, ein Fehlschlag im Log. Er findet nebenbei auch abgeschaltetes AllowOverride und Tippfehler in der erzeugten Datei. Doku korrigiert, Nginx-Vorlage ergaenzt. 4. Erstinstallation schrieb an einen Ort, an dem Linux-Anwendungen nicht lesen setup.json-Ziele waren immer installationsrelativ. Eine Anwendung, die sich unter Linux richtig verhaelt, liest aus $XDG_CONFIG_HOME - /opt/<app> ist fuer den Dienstbenutzer meist nicht schreibbar. Der Installer legte die Datei also dorthin, wo nie jemand nachsieht. Ziele haben jetzt ein "location": install (Vorgabe), config, data, home, plus ${VAR}- und %VAR%-Ersetzung in "file". Unbekannte Variablen bleiben stehen statt leer zu werden - ein Platzhalter faellt auf, ein falscher Pfad nicht. Der Installer gibt den aufgeloesten Pfad aus, weil bei config das Konto entscheidet, unter dem er laeuft. Ausserdem - Doku zeigte "status": "ok" fuer update/delete; Http::ok() erzeugt "status": "success". - UPGRADE §16.1 deckte Neuprodukte nicht ab: Fuer ein Produkt ohne Release existiert /releases/<slug>/ nicht und wird uebersprungen. Das Verzeichnis entsteht erst mit dem ersten Upload, der naechste Tick schuetzt es. Der erste ausgelieferte Build muss die Zugangsdaten also schon mitbringen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 11:47:26 +02:00
Deploymentcenter BotandClaude Opus 5	ceb977187e	feat(releases): Zugangsschutz ueber Lizenzschluessel ... /releases/ wurde bisher offen ausgeliefert, damit ausgelieferte Anwendungen ohne Zugangsdaten nach Updates suchen koennen. Das bedeutete aber auch, dass jeder im Internet die vollstaendigen Pakete herunterladen konnte - mitsamt allem, was versehentlich darin liegt. Genau so lag ein echter API-Schluessel in einer mitgelieferten appsettings.json oeffentlich abrufbar. Zugang haengt jetzt am Lizenzschluessel: Wer eine gueltige Lizenz fuer ein Produkt hat, kommt an dessen Updates. Die Anwendung kennt ihren Schluessel ohnehin und versorgt sich damit selbst - es muss nichts verteilt werden. Server - ReleaseGuard erzeugt je Produktverzeichnis .htaccess und .htpasswd. Bewusst getrennt: eine gemeinsame Datei wuerde bedeuten, dass eine Lizenz fuer Produkt A auch Produkt B oeffnet. license_licenses.product_id bindet jeden Schluessel ohnehin an genau ein Projekt. - Eingetragen werden aktive, nicht abgelaufene Lizenzen (Benutzername = Passwort = Schluessel; Basic Auth braucht zwei Felder, es gibt aber nur ein Geheimnis) sowie alle Installationskonten - bei einer Erstinstallation gibt es noch keinen Schluessel, mit dem sich das Paket holen liesse. - Deren Hash wird unveraendert aus dc_users uebernommen: password_hash() erzeugt bcrypt im Format $2y$, genau das versteht Apache. Ein Klartextpasswort wird nirgends gebraucht. Argon2-Hashes werden erkannt und uebersprungen statt eine unbrauchbare Datei zu erzeugen. - Lizenzschluessel werden mit Kosten 8 gehasht statt 12: 29 Zeichen maschineller Zufall sind kein Menschenpasswort, Apache prueft aber bei *jeder* Anfrage neu. - Geschrieben wird ueber eine temporaere Datei mit rename() - ein Abbruch wuerde sonst eine halbe Zugangsdatei hinterlassen und in dem Moment die halbe Kundschaft aussperren. - Neu erzeugt bei jeder Lizenz- und Kontoaenderung. Abgelaufene Lizenzen loesen anders als ein Widerruf nichts aus; dafuer gleicht cli/tick.php nach und erzeugt spaetestens alle sechs Stunden neu. - Statusanzeige und Schaltflaeche im WebUI unter UpdateService. Client - ReleaseCredentials: Lizenzschluessel oder Installationskonto als Basic Auth. - UpdateClient und Agent senden sie fuer latest.json und package.tar.gz. - UpdateCheckResult.Unauthorized trennt "Lizenz traegt nicht mehr" von einem Netzwerkfehler. Ohne diese Unterscheidung sucht man an der falschen Stelle. - LaunchUpdateAgent reicht licenseKey als --license-key durch. - Der Installer benutzt die beim Anmelden eingegebenen Zugangsdaten auch fuer den Paketabruf; das Setup-Token taugt dafuer nicht, weil Apache prueft und nicht die Anwendung. Sonstiges - deploy.py klammert artifacts/ aus. Ohne das landeten die gebauten Installer-Binaries zusaetzlich unter /artifacts/ im Webroot. ACHTUNG Reihenfolge: Der Schutz sperrt jede Anwendung aus, die noch mit dem alten SDK gebaut ist. Erst ausliefern, dann scharfschalten - siehe UPGRADE.md §16. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-13 11:21:49 +02:00