Robopack & Co.: Warum ein Winget-Wrapper kein Patch Management ist
In jeder Intune-Patch-Management-Demo läuft aktuell dieselbe Zahl über den Bildschirm: 30.000+ Apps, 35.000+ Apps, teilweise noch größer. Klingt beeindruckend. Ist aber die falsche Kennzahl, um ein Patch-Management-Tool zu bewerten, und genau daran hängt meine Kritik an Tools wie Robopack.
Robopack selbst macht daraus kein Geheimnis, es steht offen in der eigenen Dokumentation: Für den Patch-Katalog wird direkt das Winget Community Repository genutzt, dieselbe öffentliche GitHub-Manifest-Sammlung, aus der auch der winget-Client auf jedem Windows-Client seine Pakete zieht. Alle 30 Minuten wird auf neue Versionen geprüft, die dann per Wave Deployment ausgerollt werden.
Das ist keine versteckte Design-Entscheidung. Es ist aber eine, deren Konsequenzen in keiner Sales-Demo besprochen werden.
Was PatchMyPC stattdessen tut
Zum Vergleich, weil der Unterschied sonst abstrakt bleibt: PatchMyPC bezieht seine Pakete individuell direkt von den Herstellern, nicht aus einer Community-Sammlung. Der eigene Prozess dahinter beinhaltet unter anderem:
- Hash-Verifizierung gegen die Herstellerquelle, nicht gegen einen beliebigen Mirror
- Tests der Silent-Install-Parameter pro Version, nicht nur einmalig beim Onboarding der App
- Prüfung des Upgrade-Pfads: Ersetzt die neue Version die alte sauber, oder bleibt eine Karteileiche als Side-by-Side-Installation zurück?
- Erfassung und Validierung der tatsächlichen Exit Codes statt eines simplen „Befehl ausgeführt, wird schon passen"
PatchMyPC hat das Thema inzwischen sogar selbst offen adressiert und die eigene Positionierung explizit „Curated vs. Crowdsourced" genannt. Wenig überraschend als Wettbewerber, aber die technische Beobachtung dahinter stimmt trotzdem.
Warum das kein Nebenschauplatz ist
| Fragestellung | Winget-Repacker (z.B. Robopack) | Herstellerbasierter Packager (z.B. PatchMyPC) |
|---|---|---|
| Wer prüft die Silent-Switches? | Der Community-Contributor, der das Manifest zuletzt bearbeitet hat, unbezahlt und ohne SLA | Der Anbieter selbst, pro Version, als Teil des eigenen Produkts |
| Woher kommt der Installer? | Von der URL, die im Manifest steht, oft ein Mirror oder GitHub Release | Direkt von der Herstellerseite, Hash-verifiziert |
| Wird der Upgrade-Pfad getestet? | Nein, strukturell nicht vorgesehen | Ja, explizit gegen Side-by-Side-Leichen |
| Wer haftet bei einem kaputten Paket? | Niemand konkret, drei Parteien (du, Repacker, anonymer GitHub-Contributor) ohne klare Verantwortung | Der Anbieter, vertraglich und mit Support-Kanal |
| Version, die ausgerollt wird | Was gerade im Community Repository steht, im 30-Minuten-Takt | Was der Anbieter freigegeben hat |
Das Kernproblem ist nicht, dass Winget als Software schlecht wäre. Für den interaktiven Gebrauch auf einem einzelnen Gerät funktioniert es ordentlich. Das Problem ist, dass ein Tool, das nur eine Oberfläche und einen Scheduler um winget install herumbaut, strukturell keine der Prüfschritte einführen kann, die ein Patch-Management-Produkt eigentlich rechtfertigen. Es gibt keinen Packaging-Schritt, an dem jemand die Bloatware aus einem Installer entfernt, den eigenen Auto-Updater der App deaktiviert, damit er nicht gegen euren zentral gesteuerten Patch-Zyklus arbeitet, oder eine unternehmensspezifische Transform-Datei anwendet. Es gibt nur den Durchreich-Layer.
Und weil die Manifeste von wechselnden, anonymen Freiwilligen gepflegt werden, ist die Qualität pro App unterschiedlich und für euch als Kunde nicht vorhersehbar. Bei einer beliebten App wie VS Code ist das Manifest vermutlich gepflegt und sauber. Bei einer Nischen-App, die zufällig in eurem Unternehmen im Einsatz ist, kann das Manifest seit Monaten unangetastet, mit falschem Silent-Switch oder mit einer veralteten Download-URL im Repository liegen, und ihr würdet es erst merken, wenn die automatische Verteilung fehlschlägt oder schlimmer, wenn sie scheinbar erfolgreich durchläuft, aber eine kaputte Installation hinterlässt.
Wo das trotzdem okay ist
Damit das nicht als reine Verurteilung stehen bleibt: Für ein kleines Unternehmen unter 100 Geräten, ohne Compliance-Druck, mit einem IT-Generalisten statt einem dedizierten Packaging-Team, ist ein kostenloser Winget-Wrapper ein vernünftiger Kompromiss. Besser automatisch halbwegs aktuell gehaltene Software als gar keine. Robopack ist für genau dieses Segment auch kostenlos, das ist ehrlich positioniert.
Das Problem entsteht dort, wo dieselbe Architektur in Kontexte mit echtem Patch-SLA verkauft wird, etwa bei allem, was ich in meinem Artikel zur KRITIS-Referenzarchitektur beschrieben habe. Wenn eine kritische Schwachstelle innerhalb definierter Fristen geschlossen werden muss, ist „irgendwann in den nächsten 30 Minuten checkt ein Community-Repository nach, ob jemand die neue Version schon manifestiert hat" keine belastbare Grundlage für eine Zusage an den Vorstand oder eine Behörde.
Mein Fazit
Die Katalogsgröße, mit der Winget-Repacker werben, ist keine Eigenleistung. Sie ist die Größe eines fremden, öffentlichen GitHub-Repositorys, das der Anbieter selbst weder kuratiert noch verbessert, sondern nur alle 30 Minuten abfragt. Das ist ein legitimer Convenience-Layer, aber kein Patch Management im Sinne von geprüften, herstellerverifizierten, versionsstabilen Paketen.
Wer ein solches Tool evaluiert, sollte in der Demo genau eine Anschlussfrage stellen: „Wer hat dieses Paket getestet, und woher kommt der Installer wirklich?" Lautet die ehrliche Antwort „wir zeigen euch, was gerade in Winget steht", kauft ihr eine hübschere Oberfläche für einen Befehl, den jeder Admin auch selbst mit Winget-AutoUpdate hätte einrichten können. Das kann für euren Anwendungsfall trotzdem richtig sein. Aber es ist etwas grundlegend anderes, als was auf der Verpackung steht.