Zwei Beobachtungen aus der laufenden Integration.
1. Der Installer schrieb Geheimnisse weltlesbar
SetupWriter benutzte File.WriteAllText ohne Rechteanpassung - unter Linux
also die Standardmaske und damit ueblicherweise 644. In genau dieser Datei
stehen Lizenzschluessel und Anwendungstoken; jeder Benutzer des Systems
konnte sie lesen. Der Lizenz-Cache in StateStore wird aus demselben Grund
seit jeher auf 600 gesetzt - der Installer zog nicht nach.
Enthaelt ein Ziel mindestens einen geheimen Wert, wird die Datei jetzt auf
den eigenen Benutzer beschraenkt. Als geheim gilt type=secret UND
source=provision: ein so geholtes Token traegt oft den Typ "string", ist
aber genauso schutzbeduerftig. Unter Windows bleibt es beim Profil-ACL.
2. Zielnamen koennen plattformabhaengig unterschiedlich sein
%APPDATA%\MeineAnwendung gegen $XDG_CONFIG_HOME/meineanwendung - eine
setup.json kannte nur eine Schreibweise. Die kleingeschriebene Form allein
traegt, weil NTFS die Schreibweise ignoriert, aber nur solange das
Dateisystem tatsaechlich unempfindlich ist; auf APFS mit Beachtung der
Schreibweise oder bei groesseren Unterschieden entstuende ein zweites,
leeres Verzeichnis neben dem, aus dem die Anwendung liest.
Ziele haben deshalb optional fileWindows, fileLinux und fileMacOS; ohne
Angabe gilt weiterhin file.
Die Dokumentation haelt ausserdem fest, dass der Installer bewusst Klartext
schreibt und die Anwendung selbst entscheidet, ob und wie sie ihn danach
schuetzt - und dass eine Entschluesselung, die Klartext durchreicht, deshalb
kein Altlast-Zweig mehr ist, sondern ein aktiv genutzter Pfad.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
