Debian-Maintainer von KeePassXC entfernt alle Netzwerkfunktionen

(fosstodon.org/@keepassxc)

1 Punkte von GN⁺ 2024-05-12 | 1 Kommentare | Auf WhatsApp teilen

Wenn Debians keepassxc-Paket zu einem Paket mit Minimalfunktionen wird, müssen Nutzer, die die bisherigen Funktionen behalten wollen, auf keepassxc-full umsteigen
Der Umfang der Entfernung beschränkt sich nicht auf Networking, sondern umfasst auch YubiKey, Auto-Type, Browser-Integration, SSH Agent, FDO Secrets, Favicon-Download und HIBP
Die Debian-Paketbeschreibung erklärt, dass das Standardpaket keepassxc nur „bare minimal functionality“ bietet, und stuft Networking, SSH Agent, Browser-Plugins und FDO Secret Storage als sicherheitsrelevante Komplexität ein
Die Änderung wird über NEWS.Debian.gz und apt-listchanges kommuniziert; Nutzer von stable sollten die Release Notes prüfen
Paketname und Umstiegsverfahren sind noch anpassbar; für die Zeit nach Trixie wird erwogen, dass apt install keepassxc zwei Optionen anzeigt

Änderung am Debian-Paket `keepassxc`

Team KeePassXC informiert Debian-Nutzer darüber, dass der Paket-Maintainer von keepassxc vorhat, den Funktionsumfang stark zu reduzieren
Wenn die Änderung außerhalb von testing/sid ankommt, müssen Nutzer, die die bisherigen Funktionen benötigen, auf keepassxc-full umsteigen
Der Debian-Bugreport sieht nach einer Deaktivierung von Networking aus, doch Team KeePassXC widerspricht: Die tatsächliche Änderung komme eher einer Entfernung des gesamten Funktionsumfangs über Networking hinaus gleich

Umfang der entfernten Funktionen

Laut Team KeePassXC sollen folgende Funktionen entfernt werden
- YubiKey
- Auto-Type
- Browser-Integration
- SSH Agent
- FDO Secrets
- Networking
- Favicon-Download
- HIBP

Debian-Paketbeschreibung und Begründung

Die Beschreibung des keepassxc-Pakets in Debian sid weist darauf hin, dass das Standardpaket nur Minimalfunktionen enthält
Sie betrachtet Networking, SSH Agent, Browser-Plugins und FDO Secret Storage als sicherheitsrelevante Komplexität und empfiehlt bei Bedarf keepassxc-full
Als zugehöriger Debian-Bugreport wurde #953529 - keepassxc: Compiling with disable networking support geteilt

Position des Debian-Maintainers

Der Debian-Maintainer nennt /usr/share/doc/<package>/NEWS.Debian.gz als erste Stelle, an der unerwartete Änderungen nachzulesen sind
Nutzer von testing/unstable können Änderungen automatisch sehen, wenn apt-listchanges installiert ist; Nutzer von stable sollten die Release Notes lesen
Er erklärt, die Entscheidung sei ein Jahr lang diskutiert worden und habe sich nach dem xz-utils-Vorfall in Richtung möglichst wenig standardmäßig enthaltener Code bewegt
Der Maintainer sieht keine große Überschneidung zwischen Nutzern, die zugleich Debian, KeePassXC und einen funktionsreichen Passwortmanager wollen
Er formuliert, es ergebe keinen Sinn, in einen rein lokalen Passwortmanager „Löcher“ einzubauen

Kommunikationsproblem zwischen Upstream und Downstream

Ein Nutzer kritisiert, dass die Diskussion lange lief, die Upstream-Entwickler aber dennoch völlig überrascht zu sein scheinen
Der Debian-Maintainer antwortet, es handele sich um eine interne Angelegenheit des Debian-Projekts, und er habe andere Debian-Entwickler im IRC nach ihrer Meinung gefragt
Er erklärt, die Position von Upstream sei bereits bekannt gewesen, Upstream habe den IRC vor einigen Jahren verlassen, und schon das Packaging neuer Versionen koste genug Energie
Team KeePassXC und einige Nutzer befürchten, dass die Downstream-Entscheidung zu einer Flut von Bugreports und Verwirrung bei Upstream führen könnte

Paketname und Richtung des Umstiegs

Mehrere Nutzer schlagen vor, statt das Standardpaket keepassxc in ein Paket mit Minimalfunktionen umzuwandeln, einen Namen wie keepassxc-minimal oder keepassxc-light zu verwenden und das bestehende keepassxc mit vollem Funktionsumfang beizubehalten, um Verwirrung zu vermeiden
Ein Vorschlag sah folgende Struktur vor
- keepassxc-light
- keepassxc-full
- keepassxc als Übergangspaket, das von keepassxc-full abhängt
- Erklärung der Änderung über NEWS.Debian
Der Debian-Maintainer antwortet, eine Namensänderung hänge von der Zustimmung des ftpteam ab; für ein Trixie-Übergangspaket könne dieser Vorschlag die beste Lösung sein
Für die Zeit nach Trixie wird auch erwogen, das Übergangspaket zu entfernen, sodass apt install keepassxc zwei Auswahlmöglichkeiten anzeigt

1 Kommentare

GN⁺ 2024-05-12

Hacker-News-Kommentare

Es wirkt selbst im besten Fall fragwürdig, wenn man Funktionen, die Upstream in die Software eingebaut hat, massiv entfernt und sie dann unter demselben Namen ausliefert.
Wenn man diesen Weg gehen will, sollte man einen Fork unter einem anderen Namen veröffentlichen, damit Upstream nicht weiter mit Nutzerproblemen behelligt wird.
Das erinnert mich daran, wie der Debian-Maintainer von Chromium einst einseitig die Installation von Erweiterungen deaktivierte und der Patch am Ende zurückgenommen wurde.
Ich denke auch an den viel älteren Fall zurück, als Debian die Kernel-Schnittstelle zum Laden von binärer Firmware für Netzwerkkarten entfernte und dadurch mein Netzwerk kaputtging.
- Tatsächlich wurde nur der Build-Parameter XC_ALL auf OFF gesetzt [0], und das ist auch der Standardwert in der Upstream-CMakeLists.txt 1.
  Wenn Upstream diese Funktion für so wichtig hält, sollte zuerst der Standardwert geändert werden.
  Natürlich können Nutzer verwirrt sein, wenn nach einem Upgrade Funktionen nicht mehr gehen, aber dass ein Paket ohne Suffix dem Upstream-Standard entspricht, ist an sich ziemlich vernünftig.
  
  [0] https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  1 https://github.com/keepassxreboot/keepassxc/blob/develop/CMa...
- Die Aufgabe eines Maintainers besteht aus mehr als nur darin, Upstream zu kopieren und einzufügen.
  Er hat das Recht zu beurteilen, was für die Endnutzer der Distribution angemessen ist.
  In diesem Fall scheint es eine vernünftige sicherheitsbezogene Begründung zu geben, und ein alternatives Paket wird ebenfalls angeboten.
- Debian scheint die einzige Distribution mit dieser merkwürdigen Haltung zu sein, Upstream zu ignorieren.
  Bei zwei Upstream-Projekten, die ich betreue, hat Debian einseitig die Paketnamen geändert.
  Von dem einen habe ich erst viel später erfahren, beim anderen habe ich ausdrücklich widersprochen, und trotzdem wurde es auf eine völlig unsinnige Weise durchgezogen.
  Am Ende bin ich derjenige, der es den Nutzern erklären muss.
  
  Edit: Hier sieht man Julians Arroganz auf Debian-Seite: https://github.com/keepassxreboot/keepassxc/issues/10725#iss... — genau so etwas meine ich.
- Was Upstream gebaut hat, wurde nicht „verstümmelt“.
  Es wird eine Version ohne Plugins ausgeliefert, und dazu eine -full-Version mit Plugins.
  Wenn Plugins standardmäßig eingesteckt sind, sind sie keine Plugins mehr, sondern eingebaute Funktionen, und dieser Ansatz ist richtig.
- Wenn Apple sagen würde: „Wir haben deine App verändert, weil wir dachten, das sei sicherer“, würden die Leute mit Fackeln und Mistgabeln auf die Barrikaden gehen.
  Wenn es aber ein deb-Maintainer macht, wird es plötzlich zur Debatte.
  Wenn es ein Sicherheitsproblem gibt, dürfte die unsichere Version überhaupt nicht angeboten werden, aber genau das ist hier ja nicht der Fall.
  In einer Welt mit App Stores muss sich die Rolle des Maintainers ändern.
  Seine Aufgabe ist es, Software in der Distribution lauffähig zu machen, nicht unter demselben Namen einen Quasi-Fork nach eigenem Geschmack zu basteln.
Das wirkt wie eine ziemlich vernünftige Entscheidung.
Netzwerkfunktionen und Browser-Integration sind ein großes potenzielles Loch und ein möglicher Angriffsvektor.
Wenn man ohne netzwerkbezogene Funktionen nur einer vertrauenswürdigen Datenbank vertraut, sollte es selbst bei gefundenen Schwachstellen fast unmöglich sein, das Tool zu missbrauchen, und das ist bei einem so wichtigen Werkzeug wie einem Passwortmanager eine äußerst wünschenswerte Eigenschaft.
Der ursprüngliche Maintainer stimmte dem offenbar ebenfalls zu 1.
Das vollständige Paket mit aktiviertem Netzwerk ist in Debian ebenfalls vorhanden, also müssen Nutzer, die es wollen, nur apt install keepassxc-full ausführen, um alle Netzwerkfunktionen zu nutzen.
Upstream jedoch als „crappy“[0] zu bezeichnen, ist als Paket-Maintainer keine produktive Haltung, und auch die Paketnamen keepassxc-lite und keepassxc-full wären für Debian-Nutzer vermutlich verständlicher gewesen als keepassxc und keepassxc-full.

[0] https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

1 https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Viele Dinge sind große potenzielle Löcher und Angriffsvektoren und gleichzeitig nützlich.
  „Nützlichkeit“ kann die Sicherheit erhöhen.
  Wenn ein Passwortmanager zu schwer zu benutzen ist, hören die Leute nämlich auf, ihn zu verwenden.
  Wenn man genauer hinsieht, ist auch nicht klar, ob die Nutzung der Zwischenablage unbedingt sicherer ist als die Browser-Integration.
  Schon einfache Copy-and-Paste-Fehler können einen erheblichen Teil der Sicherheitslast der Browser-Integration wieder aufheben.
  Vor langer Zeit arbeitete ich als Vertragskraft in einem großen Unternehmen, und auf den Laptops der Account-Manager gab es ein Passwort für die Festplattenverschlüsselung, eines für den Windows-Login und eines für den AD-Login; alle mussten verschieden sein, alle paar Monate geändert werden, und die Komplexitätsanforderungen waren streng.
  Auf jedem einzelnen Laptop, den ich gesehen habe, klebte ausnahmslos ein Post-it mit allen drei Passwörtern.
  Der Punkt ist: virtuelle Security-Nerd-Sicherheit ist nicht dasselbe wie Sicherheit in der realen Welt.
  Zumindest nicht immer, und hier braucht es echte Abwägungen.

1: Wir haben als externe Auftragnehmer die Wartung einiger Mitarbeiter-Laptops übernommen.
Eigentlich hätte das nicht so laufen dürfen, aber über das firmeninterne IT-System hätte es wegen der Bürokratie viel zu lange gedauert, also war es deutlich schneller und einfacher.
Es war eben so eine Art von Unternehmen.
Das an sich war natürlich ebenfalls ein „Sicherheitsrisiko“, weil es eigentlich nicht sein sollte, dass irgendein Techniker aus einem Computergeschäft einen Laptop mit streng vertraulichen Firmendaten in die Hände bekommt.
Allerdings gab es meiner Einschätzung nach nicht besonders viel zu schützen. Es ging nur um Vertriebs-/Kundenzahlen, also Informationen, die nur für einen sehr begrenzten Personenkreis nützlich waren.

Die Browser-Integration hat einen Sicherheitsvorteil gegenüber manuellem Kopieren/Einfügen.
Die Browser-Erweiterung prüft vor dem Ausfüllen der Zugangsdaten die Seiten-URL, während manuelles Kopieren/Einfügen anfällig für Typosquatting-Domains oder Homoglyphen-Phishing ist.
Ich stimme zu, dass Netzwerkfunktionen und Browser-Integration große potenzielle Einfallstore sind, aber wie Teilnehmer im GitHub-Issue angemerkt haben, ist wichtig, dass es im Vergleich zum Gesamt-Build fast keine Tests für abgespeckte Builds gibt und beliebige Kombinationen von Build-Flags überhaupt nicht getestet werden.
Wie auch anderswo erwähnt wurde, ist eines der deaktivierten „optional“-Flags die YubiKey-Unterstützung, und dadurch werden Nutzer, die auf das neu kaputte Paket aktualisiert haben, aus ihrem Passwortmanager ausgesperrt.
Selbst wenn man nur dieses eine Flag wieder aktiviert, landet man de facto wieder in einem Zustand, den niemand testet.
Unter der Annahme, dass bestehende Nutzer auf keepassxc-full migriert wurden, stimme ich zu, dass der Name keepassxc-lite das Problem verhindert hätte.
Aber genau das ist der Punkt.
Es ist vernünftig, die sicherste Lösung zum Standard zu machen, aber ein Maintainer sollte bestehende Funktionen nicht kaputtmachen, wenn weder Upstream noch Nutzer das wollen, und schon gar nicht Nutzer aus ihrem Passwortmanager aussperren.
Dass auf GitHub von „crappy“ die Rede war, ist viel zu unhöflich; wenn ich Debian nutzen würde, hätte ich allein deswegen meine Nutzung überdacht.
Wenn das Paket mit so miserablen Funktionen vollgestopft ist, verstehe ich nicht, warum man es überhaupt pflegt.
Dann sollte man es lieber ganz entfernen und die Nutzer selbst herausfinden lassen, wie sie es richtig installieren.
Die KeepassXC-Entwickler tun mir leid; die Pflege von Open-Source-Projekten ist ohnehin schon schwer genug, ohne auch noch so etwas ertragen zu müssen.
Als ich die Bezeichnung crappy gesehen habe, war mein Respekt vor julian-klode sofort weg.
Die von drawks vorgeschlagene Lösung scheint eindeutig die richtige Wahl zu sein:

Eine geeignete Lösung wäre vermutlich, sowohl eine „-full“- als auch eine „-minimal“-Version der Software zu paketieren, in den Debian-Paketmetadaten eine Conflicts-Beziehung zwischen beiden Paketen zu definieren, beide so zu markieren, dass sie keepassxc Provides, und dem -full-Build zusätzlich das Tag Replaces: keepassxc zu geben. Dann würden bestehende Nutzer beim Paket-Upgrade die Version erhalten, die weiterhin die Funktionen des aktualisierten/ersetzten Pakets bereitstellt, während neue Nutzer selbst wählen können, welche Version sie installieren möchten.

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...

Ich verstehe nicht, warum das nicht die offensichtliche Option sein sollte.
- Weil der Maintainer eine eigene Sichtweise hatte und explizit den Standard ändern wollte.
- Das war nicht nur die offensichtliche Option, sondern genau so ist es in Debian tatsächlich passiert: https://salsa.debian.org/debian/keepassxc/-/commit/7d6d16e3f...
  
  Der ursprüngliche Beitrag ist einfach schlecht geschriebener Clickbait.
  Es wurde nichts entfernt, sondern nur in das Paket keepassxc-full verschoben.
Auf der Arch-Seite wiederum wurde das wahrscheinlich in der Nutzerschaft recht häufig installierte fwupd-Paket stillschweigend so eingerichtet, dass es von passim abhängt, und passim startet ohne ausdrückliche Zustimmung des Nutzers einen offenen Webserver auf 0.0.0.0:275001.
Außerdem verwendet passim GnuTLS, das berüchtigt dafür ist, löchriger als Schweizer Käse zu sein 2.
Ich halte das für völlig absurd und würde mich nicht wundern, wenn irgendwo in der Kette ein xz-artiger Exploit versteckt wäre.
- Man muss dafür nicht einmal fwupd bemühen.
  Das allgegenwärtige systemd-resolved kann auf Anfrage einen LLMNR-Server auf Port 5355 öffnen, also etwas, das auch als mDNS bezeichnet wird und aus der alten Microsoft-NetBIOS-Welt stammt.
  Wegen des Internets der Dinge kann inzwischen ohnehin jeder auf mein LAN zugreifen, und nun wird auch Linux noch in dieses Chaos hineingezogen.
  
  Der fwupd-Fix ist einfach, weil die Standardkonfigurationsdatei von schlechter Qualität ist und nicht einmal auskommentierte Defaults enthält:
```
# /etc/fwupd/fwupd.conf  
[fwupd]  
P2pPolicy=none  
```
  Der resolved-Fix: In /etc/systemd/resolved.conf ist LLMNR=no auskommentiert, und vermutlich will man auch DNSStubListener=no.
  Ein brauchbarer Standard wäre:
```
# /etc/systemd/resolved.conf  
[Resolve]  
DNS=9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net  
FallbackDNS=127.0.0.1 ::1  
Domains=~.  
DNSOverTLS=yes  
LLMNR=no  
DNSStubListener=no  
```
- Gut zu wissen.
  Das könnte auch als eigener Beitrag gepostet werden.
Ich finde, Paketbetreuer sollten nach dem Prinzip der geringsten Überraschung handeln und keine Kernfunktionen deaktivieren, sofern dafür kein dokumentiertes oder zumindest plausibles Risiko besteht.
In diesem Kommentarbereich fällt derzeit 25-mal das Wort „Plugin“, aber darum geht es hier nicht.
KeePassXC hat viele Funktionen, aber es gibt offenbar nichts, das allein schon ohne ausdrückliche Nutzeraktion eine wahrscheinliche Quelle für Sicherheitslücken wäre.
Die Browser-Integration muss erst aktiviert werden, bevor man sie einrichten kann, und für die anderen durch dieses Flag deaktivierten Funktionen gilt vermutlich dasselbe, daher wäre ein -minimal-Paket passender gewesen.
Der erhebliche Ärger für Leute, die die Browser-Integration genutzt haben, ist weitaus größer als der Nutzen für die sehr wenigen Nutzer, die von dieser Änderung irgendwann in einer ungewissen Zukunft profitieren könnten.
Die Browser-Integration ist im Allgemeinen auch deutlich sicherer als der Zugriff auf die Zwischenablage.
Es scheint auch nicht zur Vision des Projekts zu passen:

Das Ziel ist es, eine Anwendung zu schaffen, die jeder nutzen kann und die zugleich fortgeschrittene Funktionen für diejenigen bietet, die sie brauchen.
Diese Trennung hätte man auch schaffen können, ohne bestehende Nutzer auszusperren, daher ist das schwer anders als eine schlechte Entscheidung des Debian-Paketbetreuers zu sehen.
Dass man KeepassXC ohne Netzwerkfunktionen nutzen kann, ist natürlich gut, aber die Browser-Integration als Nischenfunktion zu betrachten, ist schon extrem realitätsfern.
Ich würde darauf wetten, dass mehr als die Hälfte, wahrscheinlich sogar deutlich mehr, der Nutzer von KeepassXC unter Debian genau die Funktionen wollen, die auf diese Weise nun ohne Vorwarnung deaktiviert werden.
Am Ende liegt die Entscheidung natürlich bei ihnen, aber das heißt nicht, dass es eine gute Entscheidung ist, und ich denke, das ist sie nicht.
Aussage eines KeePassXC-Betreuers:

Noch bevor dieser Thread begonnen hatte, lagen mir drei Berichte vor, dass diese neue Paketierungsweise den Workflow von Leuten zerstört hat. Einer betraf einen Nutzer, der wegen entfernter YubiKey-Funktionalität seine Datenbank nicht mehr öffnen konnte. Denken Sie einen Moment darüber nach. Jemand, der keinen Zugriff mehr auf seine wichtigsten Geheimnisse hat, kann in Panik geraten und dabei mitunter irrational handeln.

https://github.com/keepassxreboot/keepassxc/issues/10725#iss...
- Wenn man einen Offline-Passwortmanager nutzt und kein Backup hat, kann man auch gleich davon ausgehen, dass schon alles verloren ist.
  Das klingt wie emotionale Erpressung.
  Ich weiß nicht, wie oft ich schon alles durch Hardwaredefekte, Updates, die das Betriebssystem zerstört haben, oder durch dd auf dem falschen Laufwerk verloren habe.
Wenn ein Downstream-Betreuer Pakete anders zusammenstellt, als es das Upstream-Projekt beabsichtigt, sollte er sie meiner Meinung nach unter einem anderen Namen vertreiben und alle Bugreports, die durch diese modifizierte Version entstehen, selbst bearbeiten.
- Der Standard-Build hat Networking auf OFF.
  Dasselbe gilt für YubiKey, Browser-Integration usw.
  
  -DWITH_XC_NETWORKING=[ON|OFF] Enable/Disable Networking support (e.g., favicon downloading) (default: OFF)
  
  https://github.com/keepassxreboot/keepassxc/blob/develop/INS...
- Die Build-Option WITH_XC_NETWORKING ist standardmäßig deaktiviert, daher ist offensichtlich, dass die Entwickler diese Konfiguration als gültige Build-Konfiguration vorgesehen haben.
- Ich weiß, dass das in der Praxis oft nicht eingehalten wird, aber ursprünglich sollte der Ablauf so sein: Wenn man bei einem von der Distribution bereitgestellten Paket auf einen Bug stößt, meldet man ihn für das Distributionspaket, und der Betreuer schaut ihn sich an und reicht ihn dann an das Upstream-Projekt weiter, falls es sich um einen Upstream-Bug handelt.
  Das ist sinnvoll, weil 1. der Paketbetreuer mit dem Paket vertraut ist, die erste Einordnung und Analyse übernehmen kann und es vielleicht sogar direkt behebt, bevor es Upstream erreicht, und 2. Distributionspakete, wie gesagt, oft Patches enthalten, sodass der Betreuer prüfen muss, ob das Problem im Packaging oder im Upstream-Quellcode liegt.
  Leider melden viele Nutzer zuerst bei Upstream.
  Daher ist die Sorge in der Praxis nachvollziehbar, aber eigentlich sollte es nicht so laufen.
- Oder man sollte Endnutzern kenntlich machen, dass es sich um ein nicht unterstütztes Paket handelt.
  Zum Beispiel indem es als KeePassXC-Debian oder KeePassXC-Unsupported erscheint und im About-Dialog die Entwicklerkontakte oder Website entfernt und stattdessen Debian-Supportinformationen eingetragen werden.
  Kleine Downstream-Änderungen zur Anpassung an das Betriebssystem sind in Ordnung.
  Aber die App so zu verändern, dass Kernfunktionen entfernt werden und die Upstream-Entwickler dann eine Flut von Beschwerden abbekommen, ist nicht in Ordnung.
- Ich verstehe nicht, warum man kommentiert, ohne überhaupt den verlinkten 200-Zeichen-Beitrag gelesen zu haben.
  Der Betreuer hat im Paket keepassxc-full alle Plugins einschließlich der netzwerkbezogenen aktiviert, während das Paket keepassxc nur die Grundfunktionen mit deutlich besserer Sicherheitslage enthält.
  Das ist ganz offensichtlich völlig in Ordnung und liegt im Zuständigkeitsbereich des Betreuers.
  Die ganze Beschwerde besteht schlicht darin, dass dies eine Änderung ist.
Für Interessierte scheint dieses Issue auf GitHub die aktuellsten Kommentare zu enthalten:

https://github.com/keepassxreboot/keepassxc/issues/10725
- Die Sicht des Debian-Betreuers Julian Klode ist ziemlich scharf:
  
  Es tut mir leid, aber das wird nicht passieren. Es war ein Fehler, standardmäßig alle Plugins zu bauen und auszuliefern. Weil Nutzer die NEWS-Datei, die sie lesen sollten, nervig konsequent nicht lesen, wird es wohl etwa ein Jahr lang schmerzhaft sein, aber viel lässt sich daran nicht ändern.
  
  Es ist unsere Verantwortung, Nutzern standardmäßig die sicherstmögliche Option zu geben. All diese Funktionen sind unnötig und gehören eigentlich nicht in einen lokalen Passwortdatenbank-Manager. Diese ganze Entwicklungsrichtung ist völlig verfehlt.
  
  Nutzer, die diesen Müll brauchen, können die Müll-Version installieren, aber das erhöht natürlich das Risiko von Drive-by-Contributor-Angriffen.
Der Titel ist falsch.
Im ursprünglichen Beitrag hieß es, der Betreuer habe nicht nur Netzwerkfunktionen, sondern alle Funktionen entfernt, und das stimmte auch, weil beim Build tatsächlich alle optionalen Funktionen deaktiviert wurden, auch vollständig offline arbeitende.