Sicherheit & Vertrauen

WinMate-Skripte führen Installer mit Administratorrechten aus. Diese Seite beschreibt, was ein Skript tut, wie Pakete geprüft werden, wo die Grenzen liegen und wie sich ein Skript vor dem Ausführen verifizieren lässt.

Was ein WinMate-Skript tut

Es ruft winget, scoop oder choco für die Pakete auf, die oben im Skript stehen, und sonst nichts. Diese Liste ist vor dem Download in der Vorschau sichtbar.
Es fordert einmal Administratorrechte an. Apps, deren Installer keine erhöhten Rechte akzeptieren, laufen über eine temporäre geplante Aufgabe mit dem normalen Benutzerkonto; die Aufgabe wird danach entfernt.
Es lädt nichts von WinMate herunter. Die Installer kommen von den Herstellern, wie in den Paket-Manifesten hinterlegt.
Es schreibt ein Protokoll und einen Lauf-Datensatz nach %LOCALAPPDATA%\WinMate sowie ein Undo-Skript, das nur die in diesem Lauf installierten Apps entfernt.
Es gibt keine Telemetrie. Die Auswahl wird ausschließlich im Browser gespeichert (Datenschutz).

Ein Skript verifizieren

Aktuelle Version: 2.3.0
Engine-SHA-256: d3a662d54f9543910685884c9659132106302c97b64dcff686c121634a136322
Gebaut aus Commit: 435c9e3041f7

Jedes erzeugte Skript besteht aus einem kurzen Konfigurationsblock mit den gewählten Apps und der Engine, die in allen Skripten identisch ist. So lässt sich prüfen, dass die Engine unverändert ist:

winmate.ps1 aus dem aktuellen GitHub-Release herunterladen. Releases werden von öffentlichen GitHub Actions gebaut und tragen einen Herkunftsnachweis: gh attestation verify winmate.ps1 --repo baba537/WinMate
.\winmate.ps1 -Verify .\WinMate-Install.cmd ausführen. Der Befehl listet die Apps auf, die das Skript installiert, und meldet nur dann OK, wenn die Engine dem veröffentlichten Hash entspricht.
Alternativ den Engine-Block von Hand mit src/ps/engine.ps1 vergleichen. Die Seite wird reproduzierbar aus dem Repository gebaut, das Ergebnis lässt sich also nachbauen und vergleichen; die Hashes stehen in build-info.json.

Wie Pakete geprüft werden

winget: Manifeste in microsoft/winget-pkgs werden vor der Veröffentlichung von Microsoft validiert und gescannt. winget vergleicht den SHA-256-Hash jedes Installers mit dem Manifest und führt eine abweichende Datei nicht aus. Store-Apps liefert der Microsoft Store aus.
Chocolatey: Community-Pakete werden moderiert und auf Schadsoftware geprüft; heruntergeladene Installer müssen Prüfsummen mitbringen.
Scoop: Manifeste enthalten Hashes, die Scoop nach dem Download prüft; Buckets ändern sich über geprüfte Pull Requests.
WinMate: Ein geplanter Job prüft jede Paket-ID wöchentlich gegen die offiziellen Indizes (letzte Prüfung: 2026-09-14) und erfasst die aktuellen Versionen. Skripte nutzen exakte IDs (--exact) und eine feste Quelle und können die erfassten Versionen festschreiben.

Bedrohungsmodell

Bedrohung	Gegenmaßnahme	Restrisiko
Website oder Hosting werden kompromittiert und liefern ein verändertes Skript aus	Open Source, reproduzierbarer Build in öffentlicher CI, Skriptvorschau, Engine-Hash über `-Verify` gegen ein attestiertes Release, strenge Content-Security-Policy	Skripte, die ungelesen und ungeprüft ausgeführt werden
Eine Paketquelle oder ein Manifest wird kompromittiert	Prüfung, Scans und Hash-Kontrollen durch winget, Chocolatey und Scoop; optionales Festschreiben von Versionen	WinMate erkennt kein bösartiges Paket, das die Upstream-Quelle akzeptiert hat
Eine falsche oder bösartige Paket-ID gelangt in den Katalog	Prüfung im Pull Request, CI-Validierung gegen die offiziellen Indizes, IDs auf jeder App-Seite und im Skript sichtbar	Eine ähnlich aussehende ID wird übersehen
Typosquatting und mehrdeutige Namen	Exakte Paket-IDs (`--exact`) und feste Quelle (`--source winget`) statt Namenssuche	Gering
Missbrauch der Administrator-Sitzung	Eine Rechteerhöhung, nur für die aufgeführten Pakete; keine Dienste, keine dauerhaften Aufgaben; temporäre Dateien werden gelöscht	Die Installer selbst laufen mit vollen Rechten, das liegt in der Natur einer Softwareinstallation
Eine Installation geht schief	Lauf-Datensatz, Undo-Skript für neu installierte Apps, eine Wiederholung, ausführliche Protokolle	Ein Undo kann Änderungen außerhalb des jeweiligen Deinstallers nicht zurücknehmen

Bekannte Grenzen

Keine Authenticode-Signatur. Skripte entstehen im Browser für eine bestimmte Auswahl und lassen sich deshalb nicht signieren. Release-Dateien tragen stattdessen einen GitHub-Herkunftsnachweis, und der Engine-Hash ist veröffentlicht.
Kein unabhängiges Sicherheitsaudit. Der Code ist klein und lesbar; Reviews und Meldungen sind willkommen.
Ein Maintainer, KI-gestützte Entwicklung. Alles ist öffentlich und damit nachprüfbar.
Kein Deployment- oder Verwaltungswerkzeug. WinMate erzeugt Installationsskripte. Es gibt keine zentrale Verwaltung, keinen Offline-Spiegel und kein Compliance-Reporting.

Sicherheitslücken melden

Sicherheitsprobleme bitte vertraulich über GitHub Security Advisories melden, nicht in öffentlichen Issues. Details stehen in SECURITY.md. Falsche Paket-IDs und andere Fehler gehören in den Issue-Tracker.