Einleitung
Ein Befehl wie:
winget search firefox
wirkt zunächst sehr einfach.
Winget muss jedoch irgendwoher wissen:
- dass Firefox existiert,
- welche Version verfügbar ist,
- welcher Installer verwendet werden soll,
- wo dieser heruntergeladen werden kann,
- welche Architektur unterstützt wird,
- welcher Hash erwartet wird.
Diese Informationen kommen aus den Winget Sources.
Eine Source ist vereinfacht gesagt eine Paketquelle, die Winget Informationen über verfügbare Anwendungen liefert.
Der grundsätzliche Ablauf sieht so aus:
Winget Client
↓
Paketquelle / Source
↓
Paketinformationen
↓
Manifest
↓
Installer
↓
Installation
Sources bilden damit einen zentralen Bestandteil der Winget-Architektur.
Welche Sources sind standardmäßig vorhanden?
Aktuelle Winget-Versionen definieren drei Standardquellen:
msstore winget winget-font
msstore stellt den Microsoft-Store-Katalog bereit.
winget ist das WinGet Community Repository für Anwendungen.
winget-font ist die Community-Quelle für Schriftarten und wird standardmäßig als explizite Source behandelt. Sie wird also nicht automatisch bei jeder normalen Paketsuche berücksichtigt.
Die vorhandenen Quellen lassen sich jederzeit anzeigen:
winget source list
Die Winget Community Source
Für klassische Desktop-Anwendungen ist insbesondere die Source:
winget
wichtig.
Sie basiert auf den Paketmanifesten des WinGet Community Repository.
Dabei sollte ein wichtiges Architekturprinzip verstanden werden:
Die Source enthält im Regelfall nicht die eigentlichen Installationsdateien der Programme.
Sie stellt vielmehr Paketinformationen bereit.
Vereinfacht:
Winget Source
↓
Paketmanifest
↓
Downloadadresse
↓
Hersteller
↓
Installer
Winget lädt den Installer anschließend anhand der im Paket hinterlegten Informationen.
Damit ist die Paketquelle eher ein Softwarekatalog als ein klassisches Downloadarchiv.
Details einer Source anzeigen
Die allgemeine Übersicht erhalten wir mit:
winget source list
Möchten wir eine bestimmte Source genauer untersuchen:
winget source list --name winget
Winget kann dabei unter anderem Angaben wie Name, Typ, Argument beziehungsweise Adresse, Identifier, Vertrauensniveau, Explicit-Status und Zeitpunkt der letzten Aktualisierung anzeigen.
Das ist insbesondere bei der Fehleranalyse interessant.
Eine bestimmte Source bei der Suche verwenden
Sind mehrere Paketquellen eingerichtet, kann die gewünschte Quelle explizit angegeben werden.
Beispielsweise:
winget search firefox --source winget
Die Kurzform lautet:
winget search firefox -s winget
Auch bei der Installation kann die Source festgelegt werden:
winget install --id Mozilla.Firefox --exact --source winget
Damit wird sehr eindeutig definiert:
Paket: Mozilla.Firefox Quelle: winget
Gerade bei automatisierten Installationen kann diese Eindeutigkeit von Vorteil sein.
Explizite und implizite Sources
Neuere Winget-Versionen unterscheiden außerdem zwischen impliziten und expliziten Sources.
Eine implizite Source wird automatisch in normalen Winget-Abfragen berücksichtigt.
Eine explizite Source muss dagegen ausdrücklich angegeben werden:
--source <Source>
Die Source winget-font ist beispielsweise standardmäßig explizit.
Eine Source kann entsprechend konfiguriert werden:
winget source edit <Source> --explicit true
Oder wieder implizit:
winget source edit <Source> --explicit false
Dieses Konzept ist gerade für Unternehmensquellen ausgesprochen interessant.
Warum explizite Sources sinnvoll sind
Angenommen, ein Unternehmen betreibt ein internes Repository:
company
Dort liegen beispielsweise freigegebene interne Anwendungen.
Wird die Source als explizit konfiguriert, taucht sie nicht automatisch bei jeder allgemeinen Suche auf.
Stattdessen muss bewusst beispielsweise:
winget search Fachverfahren --source company
verwendet werden.
Das schafft eine klarere Trennung zwischen:
öffentlichen Paketen
und
internen Unternehmenspaketen
Sources aktualisieren
Winget hält lokale Informationen über seine Paketquellen vor.
Diese können manuell aktualisiert werden:
winget source update
Damit werden alle Sources aktualisiert.
Für eine einzelne Source:
winget source update --name winget
Alternativ existiert der Alias:
winget source refresh
Microsoft dokumentiert refresh als Alias für update.
Vor umfangreichen Installationen kann ein Source-Update sinnvoll sein.
Eine neue Source hinzufügen
Winget erlaubt das Hinzufügen weiterer Paketquellen.
Die grundsätzliche Syntax lautet:
winget source add --name <Name> --arg <Adresse>
Ein schematisches Beispiel:
winget source add `
--name company `
--arg https://packages.example.org/cache
Das Hinzufügen einer Source verändert den Zugriff des Benutzers auf Paketquellen und benötigt deshalb Administratorrechte.
Der Name:
company
kann anschließend verwendet werden:
winget search <Paket> --source company
Der Typ einer Source
Beim Hinzufügen kann zusätzlich der Typ angegeben werden:
--type
Aktuell unterstützt Winget unter anderem:
Microsoft.PreIndexed.Package Microsoft.Rest
Microsoft.PreIndexed.Package ist der standardmäßige Source-Typ.
Microsoft.Rest bezeichnet eine Windows-Package-Manager-REST-API-Source.
Ein entsprechender Aufruf kann schematisch so aussehen:
winget source add `
--name company `
--arg https://packages.example.org/api `
--type Microsoft.Rest
Welche Variante verwendet werden muss, hängt von der bereitgestellten Repository-Infrastruktur ab.
Source direkt als explizit hinzufügen
Eine neue Quelle kann bereits beim Hinzufügen als explizit gekennzeichnet werden:
winget source add `
--name company `
--arg https://packages.example.org/api `
--type Microsoft.Rest `
--explicit
Anschließend muss sie bewusst angesprochen werden:
winget search InternesPaket --source company
Für sensible oder spezielle Unternehmensquellen ist das eine interessante Möglichkeit.
Vertrauensniveau einer Source
Beim Hinzufügen einer Source kennt Winget außerdem:
--trust-level
Microsoft nennt derzeit:
none trusted
als mögliche Werte.
Damit wird deutlich:
Nicht jede beliebige Quelle sollte einfach in Winget eingebunden werden.
Eine Source beeinflusst schließlich, welche Pakete Winget einem Benutzer zur Installation anbietet.
Nur vertrauenswürdige Sources verwenden
Microsoft weist ausdrücklich darauf hin, nur sichere und vertrauenswürdige Sources zu verwenden.
Das ist aus Sicherheitsgründen entscheidend.
Eine manipulierte oder nicht vertrauenswürdige Paketquelle könnte beispielsweise auf unerwünschte Installationsdateien verweisen.
Vor dem Hinzufügen einer Source sollte deshalb geprüft werden:
- Wer betreibt die Quelle?
- Wie wird sie administriert?
- Ist die Verbindung geschützt?
- Wer darf Pakete veröffentlichen?
- Wie werden Änderungen kontrolliert?
- Wie erfolgt die Paketfreigabe?
- Welche Installer werden referenziert?
Eine Source ist Bestandteil der Software-Lieferkette und damit sicherheitsrelevant.
Source Agreements
Eine Paketquelle kann eigene Vereinbarungen verlangen.
Werden diese nicht akzeptiert, kann Winget nicht auf die betreffende Source zugreifen.
Für automatisierte Abläufe existiert:
--accept-source-agreements
Beispielsweise:
winget source add `
--name company `
--arg https://packages.example.org/api `
--accept-source-agreements
Auch hier gilt:
Die automatische Annahme sollte nur erfolgen, wenn die entsprechenden Bedingungen bekannt und akzeptiert sind.
Sources entfernen
Eine nicht mehr benötigte Source kann entfernt werden:
winget source remove --name company
Alternativ:
winget source rm --name company
rm ist ein Alias für remove.
Auch das Entfernen einer Source benötigt Administratorrechte.
Anschließend empfiehlt sich:
winget source list
um den aktuellen Zustand zu kontrollieren.
Sources exportieren
Interessant für standardisierte Systeme ist:
winget source export
Damit lassen sich Informationen über die aktuell konfigurierten Sources exportieren.
Das ist beispielsweise für:
- Dokumentation,
- Referenzsysteme,
- Unternehmenskonfigurationen,
- Fehlersuche
hilfreich.
Microsoft verweist auch bei der zentralen Konfiguration zusätzlicher beziehungsweise zugelassener Sources auf die Ausgabe von winget source export.
Was bedeutet Priorität bei Winget?
Bei mehreren Paketquellen stellt sich zwangsläufig die Frage:
Welche Source gewinnt?
Hier sollte Winget nicht wie ein klassischer Linux-Paketmanager mit einer frei nummerierbaren Repository-Prioritätsliste betrachtet werden.
Für eine zuverlässige Steuerung ist es sinnvoller, die gewünschte Source explizit auszuwählen:
winget install `
--id Hersteller.Anwendung `
--exact `
--source company
Damit muss Winget nicht zwischen mehreren möglichen Sources entscheiden.
Zusätzlich können spezielle Quellen als explicit konfiguriert werden.
Für automatisierte Installationen ist dieses Verfahren wesentlich transparenter als sich auf eine implizite Auswahl zu verlassen.
Beispiel für eine kontrollierte Quellenstrategie
Ein Unternehmen könnte beispielsweise folgende Strategie verwenden:
Öffentliche Anwendungen
↓
winget
Microsoft-Store-Anwendungen
↓
msstore
interne Anwendungen
↓
company
spezielle interne Source
↓
explicit
Installationen aus der internen Source erfolgen dann beispielsweise bewusst mit:
winget install `
--id Firma.Fachverfahren `
--exact `
--source company
Damit wird nachvollziehbar festgelegt, aus welchem Softwarekatalog ein Paket stammt.
Unternehmensquellen
Für Unternehmen ist die Möglichkeit eigener Paketquellen besonders interessant.
Ein internes Repository kann beispielsweise Anwendungen enthalten, die im öffentlichen Winget-Repository nicht vorhanden sein sollen:
ERP-Client Fachverfahren VPN-Client interne Administrationswerkzeuge eigene Anwendungen spezielle Unternehmenssoftware
Das Unternehmen kann damit einen eigenen Softwarekatalog aufbauen.
Warum eine Unternehmensquelle sinnvoll sein kann
Eine eigene Source bietet mehrere Vorteile.
Das Unternehmen entscheidet, welche Pakete bereitgestellt werden.
Dadurch kann beispielsweise ein kontrollierter Prozess entstehen:
Neue Software
↓
Sicherheitsprüfung
↓
Lizenzprüfung
↓
Funktionstest
↓
Freigabe
↓
Manifest erstellen
↓
Unternehmens-Source
↓
Installation auf Clients
Damit wird Winget Bestandteil eines geregelten Softwarebereitstellungsprozesses.
Winget als Self-Service-Werkzeug
Eine interne Source könnte auch Grundlage eines kontrollierten Software-Self-Service sein.
Ein Benutzer beziehungsweise Administrator sucht beispielsweise:
winget search --source company
und sieht ausschließlich intern bereitgestellte Pakete.
Anschließend:
winget install `
--id Firma.FreigegebeneSoftware `
--exact `
--source company
Das Unternehmen behält damit die Kontrolle über die angebotenen Pakete.
Sources zentral per Richtlinie steuern
Im Unternehmensumfeld können Winget-Einstellungen außerdem über Richtlinien gesteuert werden.
Microsoft stellt beispielsweise Richtlinien für zusätzliche Sources und zugelassene Sources bereit. Zusätzliche, von der Unternehmens-IT vorgegebene Quellen können so zentral eingerichtet werden. Entsprechend konfigurierte zusätzliche Sources können von den Benutzern nicht einfach entfernt werden.
Das ist wesentlich kontrollierter als ein manuelles:
winget source add
auf jedem einzelnen Arbeitsplatz.
Nur zugelassene Sources erlauben
Noch interessanter ist eine Richtlinie für Allowed Sources.
Damit kann die IT festlegen, welche zusätzlichen Sources Benutzer überhaupt hinzufügen oder entfernen dürfen. Wird diese Richtlinie aktiviert, sind nur die definierten Quellen zulässig.
Das kann verhindern, dass Benutzer beliebige externe Paketquellen in eine administrierte Umgebung einbinden.
Aus Sicherheitssicht ist das besonders relevant.
Fehleranalyse: Sources zunächst auflisten
Wenn Winget plötzlich keine Pakete mehr findet, sollte die Fehlersuche bei den Sources beginnen.
Erster Schritt:
winget source list
Prüfen Sie:
Ist die erwartete Source vorhanden? Ist die Adresse korrekt? Ist die Source explizit? Wann wurde sie zuletzt aktualisiert?
Danach:
winget source update
Einzelne Source testen
Bei Problemen mit einer bestimmten Source:
winget source update --name winget
Anschließend beispielsweise:
winget search firefox --source winget
Damit lässt sich eingrenzen, ob das Problem tatsächlich die Source oder Winget insgesamt betrifft.
Fehler: Paket wird nicht gefunden
Angenommen:
winget search Anwendung
liefert keinen Treffer.
Dann kann zunächst gezielt die Quelle angegeben werden:
winget search Anwendung --source winget
Bei einer Unternehmensquelle:
winget search Anwendung --source company
Mögliche Ursachen sind:
- Paket existiert nicht in dieser Source,
- Source ist nicht aktuell,
- Source ist nicht erreichbar,
- Source ist explizit und wurde nicht angegeben,
- Netzwerkzugriff ist blockiert,
- Paketname beziehungsweise ID ist falsch.
Fehler: Source kann nicht aktualisiert werden
Schlägt:
winget source update
fehl, kommen insbesondere folgende Ursachen infrage:
- Internetverbindung
- DNS
- Proxy
- Firewall
- TLS-Inspection
- Zertifikate
- nicht erreichbarer Repository-Server
- fehlerhafte Source-Konfiguration
- Authentifizierung bei Unternehmensquellen
Aktuelle Winget-Versionen unterstützen für entsprechende Aufrufe außerdem:
--proxy
und:
--no-proxy
zur gezielten Steuerung der Proxyverwendung.
Winget hinter einem Unternehmensproxy
In Unternehmensnetzen ist ein Proxy eine häufige Ursache für Probleme.
Für einen konkreten Aufruf kann beispielsweise ein Proxy angegeben werden:
winget source update `
--proxy https://proxy.example.org:8080
Alternativ kann die Proxyverwendung für diesen Aufruf deaktiviert werden:
winget source update --no-proxy
Welche Konfiguration sinnvoll ist, hängt von der jeweiligen Netzwerkinfrastruktur ab.
Ausführliche Logs aktivieren
Für die Fehleranalyse steht:
--verbose-logs
zur Verfügung.
Beispielsweise:
winget source update --verbose-logs
Die Protokolle können außerdem geöffnet werden:
winget source update --open-logs
Damit erhält man wesentlich mehr Informationen über die Ursache eines fehlgeschlagenen Source-Zugriffs.
Winget-Systeminformationen anzeigen
Bei schwer nachvollziehbaren Problemen ist außerdem:
winget --info
sehr hilfreich.
Der Befehl zeigt unter anderem:
- Winget-Version,
- Systemarchitektur,
- App-Installer-Version,
- Winget-Verzeichnisse,
- Logpfade,
- konfigurierte Gruppenrichtlinien,
- Admin-Einstellungen.
Microsoft empfiehlt diese Informationen ausdrücklich auch für die Fehlersuche.
Sources zurücksetzen
Wenn die Standardquellen beschädigt oder falsch konfiguriert sind, können sie zurückgesetzt werden.
Der Befehl lautet:
winget source reset --force
Dabei ist Vorsicht geboten.
Microsoft bezeichnet reset ausdrücklich als Funktion für Ausnahmefälle. Beim vollständigen Reset werden zusätzliche Sources entfernt und die Standardkonfiguration wiederhergestellt. Administratorrechte und --force sind erforderlich.
Vorher sollte deshalb unbedingt:
winget source list
ausgeführt und gegebenenfalls die Konfiguration dokumentiert werden.
Nach einem Reset
Anschließend:
winget source list
und:
winget source update
Danach kann beispielsweise getestet werden:
winget search --id Mozilla.Firefox --exact --source winget
Funktioniert diese Suche wieder, war wahrscheinlich die Source-Konfiguration Teil des Problems.
Typischer Troubleshooting-Ablauf
Ein systematischer Ablauf kann so aussehen:
Paket nicht gefunden
↓
winget --info
↓
winget source list
↓
richtige Source vorhanden?
↓
winget source update
↓
gezielte Suche mit --source
↓
Netzwerk / Proxy / DNS prüfen
↓
Verbose Logs auswerten
↓
erst als letzte Maßnahme:
source reset
Damit wird verhindert, dass unnötig sofort die gesamte Source-Konfiguration zurückgesetzt wird.
Sicherheit von Paketquellen
Sources gehören zur Software-Lieferkette.
Eine mögliche Lieferkette sieht beispielsweise so aus:
Paketautor
↓
Manifest
↓
Repository
↓
Winget Source
↓
Winget Client
↓
Installer
↓
Windows-System
Wird eine Komponente dieser Kette kompromittiert, kann dies Auswirkungen auf die Sicherheit der Softwarebereitstellung haben.
Deshalb sollten Unternehmensquellen genauso sorgfältig abgesichert werden wie andere Softwareverteilungssysteme.
Best Practices
Für die Verwaltung von Winget-Sources sind einige Grundregeln besonders sinnvoll:
- Nur vertrauenswürdige Quellen verwenden.
- Eine zusätzliche Source erweitert die Software-Lieferkette.
- Sources dokumentieren.
- Es sollte nachvollziehbar sein, warum eine zusätzliche Quelle eingerichtet wurde.
- Unternehmensquellen möglichst zentral verwalten.
- Richtlinien sind für größere Umgebungen geeigneter als manuelle Clientkonfigurationen.
- Spezielle Sources als explizit konfigurieren.
- Dadurch werden sie nur bei bewusster Auswahl verwendet.
- Bei Skripten die Source explizit angeben.
- Beispielsweise:
winget install `
--id Firma.Anwendung `
--exact `
--source company
- Sources regelmäßig aktualisieren.
winget source update
- Vor einem Reset die Konfiguration sichern beziehungsweise dokumentieren.
- Verbose Logs für die Fehleranalyse verwenden.
- Proxy-, Firewall- und Zertifikatsanforderungen dokumentieren.
- In Unternehmen die zulässigen Paketquellen organisatorisch und technisch kontrollieren.
Die wichtigsten Befehle dieses Artikels
Sources anzeigen:
winget source list
Details einer Source:
winget source list --name winget
Alle Sources aktualisieren:
winget source update
Bestimmte Source aktualisieren:
winget source update --name winget
Source hinzufügen:
winget source add `
--name company `
--arg <Adresse>
REST-Source hinzufügen:
winget source add `
--name company `
--arg <Adresse> `
--type Microsoft.Rest
Source als explizit konfigurieren:
winget source edit company --explicit true
Source entfernen:
winget source remove --name company
Sources exportieren:
winget source export
Gezielt in einer Source suchen:
winget search <Paket> --source company
Gezielt aus einer Source installieren:
winget install `
--id <Paket-ID> `
--exact `
--source company
Verbose Logging:
winget source update --verbose-logs
Winget-Informationen:
winget --info
Standard-Sources zurücksetzen:
winget source reset --force
Fazit
Winget Sources bilden das Fundament der Paketverwaltung.
Sie beantworten die zentrale Frage:
Woher erhält Winget seine Informationen über verfügbare Software?
Mit:
winget source list
können die eingerichteten Paketquellen überprüft und mit:
winget source update
aktualisiert werden.
Zusätzliche Sources lassen sich mit:
winget source add
einbinden und nicht mehr benötigte Quellen mit:
winget source remove
wieder entfernen.
Besonders interessant sind explizite Sources. Sie müssen bei einer Suche oder Installation bewusst angegeben werden und ermöglichen damit eine klarere Trennung unterschiedlicher Softwarekataloge.
Im Unternehmensumfeld eröffnet dies zusätzliche Möglichkeiten. Interne Anwendungen können über eigene Paketquellen bereitgestellt und Sources zentral über Richtlinien kontrolliert werden.
Gleichzeitig entsteht daraus Verantwortung: Eine Paketquelle ist Bestandteil der Software-Lieferkette und sollte entsprechend abgesichert, dokumentiert und kontrolliert werden.
Wer Winget professionell einsetzen möchte, sollte deshalb nicht nur wissen, welche Pakete installiert werden, sondern ebenso genau festlegen, aus welchen Quellen diese Pakete stammen dürfen.
