1967b49ad77588f867e5e85e2458f00ad97b3e29
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 Deploymentcenter BotandClaude Opus 5
|
1967b49ad7 |
fix(client): Schluessel raus aus argv, Wartezeit einstellbar, Packager sperrt
Fuenf von sechs Befunden einer externen Integration. Der sechste - unsignierte Lizenzurteile - ist bestaetigt, aber bewusst nicht Teil dieses Commits. 1. Lizenzschluessel stand in der Kommandozeile Der Agent nahm --license-key nur als Argument und las keine Umgebungsvariablen. "ps" zeigt argv jedem Benutzer der Maschine - exakt die Begruendung, mit der UPGRADE.md §5 den Crontab-Weg verwirft. Damit nahm das SDK einen bereits geloesten Sicherheitsbefund zurueck. Der Agent liest jetzt DC_LICENSE_KEY, DC_DOWNLOAD_USER und DC_DOWNLOAD_PASSWORD, Umgebung vor Argument. LaunchUpdateAgent uebergibt den Schluessel nicht mehr als Argument, sondern setzt die Variable auf dem eigenen Prozess: das Kind erbt den Umgebungsblock, danach wird sie wieder entfernt. Das funktioniert auch mit UseShellExecute=true, wo sich ProcessStartInfo.Environment nicht setzen laesst. 2. --wait-timeout war nicht durchgereicht Der Agent kannte den Parameter, LaunchUpdateAgent hatte keinen dafuer - es galten fest 60 Sekunden. Eine Anwendung, die allein fuer host.StopAsync 30 Sekunden braucht, kommt damit gefaehrlich nah an die Grenze. Neu: waitTimeoutSeconds. Ausserdem ist im Quelltext und in der Doku jetzt festgehalten, dass exitCurrentApp:true ueber Environment.Exit(0) laeuft und damit finally-Bloecke und IHostApplicationLifetime uebergeht - bei offenem Zustand die falsche Wahl. 3. ILicensePrompt war tot Der Konstruktor nahm es entgegen, legte es in _prompt ab und benutzte es nirgends. Wer darauf eine headless-Story aufbaute, baute auf Sand. Neu: EnsureLicensedAsync() - zwischengespeicherten Schluessel nehmen, sonst fragen, pruefen, bei Ablehnung erneut fragen. allowPrompt:false lehnt ohne Cache ab, statt auf eine Eingabe zu warten, die im Dienst nie kommt. Ein voruebergehender Netzfehler fuehrt nicht zur erneuten Abfrage - der Schluessel ist ja nicht falsch. 4. Der Packager warnte nur Er bricht jetzt ab. Anlass war ein echter API-Schluessel in einem oeffentlich abrufbaren Paket - und die Warnung war damals ausgerechnet unterdrueckt, weil die Datei auf der preserve-Liste stand. Zwei Stufen: Dateiname (appsettings.Local.json, master.key, *.pfx, *.db, server_settings.xml) und Inhalt (gefuelltes Password=, sk-, ghp_, dc_master_, AKIA, private Schluessel). Die Inhaltspruefung findet auch Dateien mit unverdaechtigem Namen. Platzhalter loesen bewusst nicht aus: "sk-DEIN-SCHLUESSEL-HIER" haette sonst jede ausgelieferte Vorlage blockiert, und --allow-secrets waere nach einer Woche Gewohnheit. Beim Erproben zuerst genau in diese Falle gelaufen. 5. BuildInfo.targets war nur per Pfad-Import zu haben Die Anleitung empfahl einen <Import> ins Nachbar-Repository - das setzt voraus, dass beide Arbeitskopien nebeneinander liegen und in derselben Fassung stehen. Das Client-Projekt ist jetzt packbar und legt das Target unter build/ ins Paket, wo NuGet es selbst importiert. Ausserdem: Unauthorized wurde nur im statischen Zweig erkannt, im API-Zweig kam ein 401 als gewoehnlicher HTTP-Fehler an. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
Deploymentcenter BotandClaude Opus 5
|
e01a608c08 |
feat(release): Veroeffentlichungsvorlage fuer fremde Projekte
Die Anleitung benutzte pack-and-deploy, als laege es im PATH - beziehbar war es nirgends. Ein Projekt, das den UpdateService einbindet, konnte also nicht veroeffentlichen, ohne dieses Repository auszuchecken und selbst zu uebersetzen. Das Werkzeug existierte, nur kam niemand daran. - build_installer.ps1 baut pack-and-deploy fuer dieselben Laufzeitkennungen mit und fuehrt es in installer.json unter "tools". Damit steht es neben dem Agenten unter /installer/ bereit. - Neue Vorlage unter public/docs/release-template/: release.ps1, release.sh und release.config.example.json. Kopieren, Konfiguration ausfuellen, fertig - die Skripte selbst bleiben unveraendert und lassen sich bei einer neuen Fassung einfach ersetzen. - Sie orchestrieren nur: je Laufzeitkennung einmal dotnet publish, dann pack-and-deploy. Pruefsummen, Dateimanifest, latest.json und die Anmeldung bleiben im Werkzeug - ein zweiter Ort fuer dieselbe Logik waere ein zweiter Ort fuer dieselben Fehler. - Das Werkzeug wird beim ersten Lauf selbst geholt, gegen die .sha256 geprueft und unter .dc-tools/ abgelegt. Die Vorlage ist damit wirklich eine Datei. - setup.json wird ins Publish-Verzeichnis kopiert, sonst faende der Installer sie nicht. - Rueckgabewert 1 (Konfigurations- oder Versionsfehler) bricht sofort ab; die weiteren Plattformen wuerden genauso scheitern. Bei 2 laeuft es weiter und meldet am Ende, welche betroffen sind. Anleitung: public/docs/release.md, oeffentlich unter /docs/release.md - dort, wo auch das Bugtracker-Handbuch liegt. Das Entwickler-docs/ wird nicht ausgeliefert; ein erster Anlauf legte die Vorlage dort ab und war deshalb nicht abrufbar. Beim Erproben in einem leeren Projekt aufgefallen und behoben: - Die Vorlage verlangte jq. Das ist auf den wenigsten Systemen vorinstalliert; sie kommt jetzt auch mit Python aus. - Windows legt unter WindowsApps einen python3-Platzhalter ab, der gefunden wird, beim Aufruf aber nur auf den Store verweist. Die Erkennung erprobt den Interpreter deshalb, statt nur seine Existenz zu pruefen. - Der Ternary-Operator in release.ps1 gibt es erst ab PowerShell 7; die Vorlage laeuft jetzt auch mit dem mitgelieferten 5.1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |