VitosUpdater

VitosUpdater ist eine einheitliche Oberfläche zum Suchen, Installieren, Aktualisieren und Deinstallieren von Software über mehrere Paketmanager unter Windows 10/11. Die Oberfläche ist vollständig deutsch.

Stand: Phase 1 (WinGet, Entdecken/Installiert/Updates) und der Selbst-Updater sind umgesetzt. Warteschlange, weitere Paketmanager, Bundles, Tray und Backup folgen in den nächsten Phasen.

Funktionen (aktueller Stand)

• WinGet-Erkennung beim Start (PATH, danach %LOCALAPPDATA%\Microsoft\WindowsApps) mit Versionsanzeige; Hinweis und Ein-Klick-Installation des „App-Installers“, falls WinGet fehlt
• Optional: PowerShell-Modul Microsoft.WinGet.Client (strukturierte JSON-Daten); ohne Modul wird die lokalisierte Tabellenausgabe von winget.exe ausgewertet
• Ansichten: Pakete entdecken (Suche), Software-Updates (mit Zähler in der Seitenleiste), Installierte Pakete – mit Details-Panel und virtualisierter Tabelle (flüssig auch mit 5000+ Zeilen)
• Dunkles Design (Standard), helles Design, „System folgen“, Akzentfarbe wählbar
• Fensterposition und -größe werden gemerkt
• Selbst-Update von VitosUpdater (siehe unten)

Voraussetzungen

Komponente	Hinweis
Rust (rustup, MSVC-Toolchain)	rustup default stable-x86_64-pc-windows-msvc
Node.js LTS	inkl. npm
WebView2-Laufzeit	unter Windows 11 vorinstalliert
Visual Studio Build Tools	Workload „Desktopentwicklung mit C++“
Tauri CLI	cargo install tauri-cli --version "^2"
WinGet	Teil des „App-Installers“ (Microsoft Store)

Entwickeln und Bauen

npm install            # einmalig
cargo tauri dev        # Entwicklungsmodus mit Hot Reload

npm run check          # Frontend-Typprüfung (svelte-check)
cd src-tauri
cargo check
cargo clippy --all-targets -- -D warnings
cargo test             # inkl. Parser-Tests mit echter WinGet-Ausgabe

.\build.ps1            # Prüfungen + Installer (NSIS) + portable EXE

Der portable Build liegt unter src-tauri\target\release\vitos-updater.exe, der Installer unter src-tauri\target\release\bundle\nsis\.

Konfiguration, Zustand und Logs liegen in %APPDATA%\VitosUpdater (Logs unter logs\).

Selbst-Update über Gitea

VitosUpdater prüft nach dem Start und danach alle 30 Minuten (einstellbar unter Einstellungen → Programm-Updates, auch bei ausgeblendetem Fenster), ob eine neue Version vorliegt. Quelle:

https://gitea.davito.synology.me/Davito/VitosUpdater/releases/download/latest/latest.json

• Updates werden mit einem Minisign-Schlüsselpaar signiert und vor der Installation geprüft. Zusätzlich ist requireSignedVersion aktiv: Die Signatur ist an die Versionsnummer gebunden, ein Downgrade durch eine manipulierte latest.json ist nicht möglich.
• Die Versionen werden nach SemVer verglichen; es werden nie ältere Versionen angeboten.
• Bei einem neuen Update erscheint ein Popup mit Versionswechsel, Datum, Größe und den Release-Notizen. Möglich sind „Jetzt aktualisieren“, „Später erinnern“ (4 Stunden) und „Diese Version überspringen“. Eine übersprungene Version unter Einstellungen wieder freigeben.
• Ist das Fenster ausgeblendet oder minimiert, erscheint zuerst eine Windows-Benachrichtigung. Das Popup wird gezeigt, sobald das Fenster wieder geöffnet wird. Nach der Installation startet VitosUpdater neu und zeigt „Aktualisiert auf Version x.y.z“ mit den Änderungen.

Zertifikat (Synology / Gitea)

Der Updater nutzt den Windows-Zertifikatsspeicher (Schannel) und prüft das TLS-Zertifikat immer. Die Prüfung wird nicht abgeschaltet. Der Server gitea.davito.synology.me verwendet derzeit ein öffentlich vertrauenswürdiges Let's-Encrypt-Zertifikat.

Erscheint in der App die Meldung „… weil Windows dem Zertifikat nicht vertraut“ (z. B. bei einem selbst signierten Synology-Zertifikat), die Zertifizierungsstelle in Windows als vertrauenswürdig eintragen:

1. DSM: Systemsteuerung → Sicherheit → Zertifikat → Aktion → Zertifikat exportieren; aus dem Archiv die Datei syno-ca-cert.crt (die CA, nicht den privaten Schlüssel) entnehmen.
2. In PowerShell (ohne Administratorrechte, gilt für den aktuellen Benutzer):

   Import-Certificate -FilePath "$env:USERPROFILE\Downloads\syno-ca-cert.crt" -CertStoreLocation Cert:\CurrentUser\Root
   

   Für alle Benutzer (Administrator): -CertStoreLocation Cert:\LocalMachine\Root.
3. VitosUpdater neu starten.

Prüfen lässt sich die Verbindung mit curl.exe -I https://gitea.davito.synology.me.

Release veröffentlichen

Alles erledigt scripts\release.ps1 (Version erhöhen, bauen, signieren, latest.json, Commit, Tag, Push, Gitea-Release, rollendes Release latest, Prüfung):

powershell -ExecutionPolicy Bypass -File scripts\release.ps1            # Patch-Version
powershell -ExecutionPolicy Bypass -File scripts\release.ps1 -Bump minor
powershell -ExecutionPolicy Bypass -File scripts\release.ps1 -Version 1.2.0
powershell -ExecutionPolicy Bypass -File scripts\release.ps1 -NoPublish # nur bauen, Ergebnis in release-out\

Commit-Nachrichten auf Deutsch schreiben: Sie bilden die Release-Notizen im Update-Popup.

Einmalige Einrichtung

1. Zugriffstoken: Gitea → Einstellungen → Anwendungen → Zugriffstoken, Berechtigung Repository: Lesen und Schreiben (write:repository). Danach entweder dauerhaft setx GITEA_TOKEN "<token>" (neues Terminal öffnen) oder die Zeile GITEA_TOKEN=<token> in die Datei .env.local im Projektordner schreiben. Beides ist von Git ausgeschlossen.
2. Git-Push: läuft über den Windows Git Credential Manager (beim ersten Push anmelden).
3. Signierschlüssel: liegt unter %USERPROFILE%\.vitosupdater\updater.key (außerhalb des Repos, nur für den Benutzer lesbar). Unbedingt sichern (z. B. Passwortmanager oder verschlüsseltes Backup): Ohne diesen Schlüssel können keine Updates für bereits installierte Versionen signiert werden. Neu erzeugen: cargo tauri signer generate -w "%USERPROFILE%\.vitosupdater\updater.key" – danach den öffentlichen Schlüssel in src-tauri\tauri.conf.json (plugins.updater.pubkey) eintragen; alle bereits installierten Versionen müssten dann manuell neu installiert werden.

Optional kann der Schlüssel über TAURI_SIGNING_PRIVATE_KEY bzw. TAURI_SIGNING_PRIVATE_KEY_PATH (und TAURI_SIGNING_PRIVATE_KEY_PASSWORD) bereitgestellt werden.

Bekannte Einschränkungen

• Das PowerShell-Modul Microsoft.WinGet.Client wird beim Start erkannt und genutzt, wenn vorhanden. Diese Strecke ist mangels installiertem Modul auf dem Entwicklungsrechner noch nicht mit echten Daten getestet; bei jedem Fehler wird automatisch auf die Kommandozeile zurückgegriffen.
• Die Beschreibung in den Paketdetails übernimmt die Zeilenumbrüche von WinGet.
• Ein Klick auf die Windows-Benachrichtigung öffnet das Fenster nicht zuverlässig; das Popup erscheint, sobald das Fenster geöffnet oder fokussiert wird.