EXE-fizierung von Linux-Paketen

Hinweis: Dieser Artikel richtet sich an Ein- und Umsteiger:innen.

Mit dem Fortschreiten von Linux auf dem Desktop, steigt die Nutzerbasis und damit auch der Unfug, den man damit treiben kann. Damit meine ich Ein- und Umsteiger:innen, die Linux als bessere, freiere und sicherere Umgebung für ihre IT-Bedürfnisse gewählt haben. Es ist verständlich, dass damit auch der Wunsch nach einer Fülle von Anwendungen und einer einfachen Installation einhergeht.

Wer von Windows auf Linux wechselt, hat vielleicht das alte Verhalten beibehalten, Software von überall zu installieren. Man geht auf eine beliebige Webseite und lädt von dort eine Software herunter, doppelklickt die EXE-Datei, fertig ist die Malware. Leider sehe ich auch bei Linux-Paketen diesen hausgemachten Trend.

Nicht Apple hat den App-Store erfunden, sondern die ersten Linux-Distributionen. Jede Distro bietet einen Paketmanager an, der (in erster Linie) die Anwendungspakete aus den eigenen Repositories bezieht. Dahinter stehen die Maintainer, welche die Integrität der Pakete garantieren (sollen). Der Nachteil dieser Lösung besteht darin, dass die grossen Distributionen eigene Paketformate in ihren eigenen Repositories pflegen, die für eben diese Distro gedacht sind, aber nicht für andere.

Um dieses Problem zu lösen, wurden distributionsübergreifende Formate erdacht. Die Relevanten heissen: Snap, Flatpak und AppImage. Die Tatsache, dass es mindestens drei davon gibt, zeigt, dass das Problem nicht gelöst wurde. Hinzu kommt, dass die Distro-eigenen keinesfalls durch die allgemeinen Pakete abgelöst wurden. Somit zeigt sich heute dieses Bild:

• Distributionsspezifische Paketformate: DEB, RPM, Arch-Paket (.pkg.tar.zst), APK.
• Snap-Pakete (nur bei Ubuntu/Canonical)
• Flatpak (z. B. bei flathub.org)
• AppImages
• Installationsskripte, die über curl aus dem Internet laden.

Der Auslöser für diesen Artikel war die Software WayScriber. Damit kann man auf einen Desktop schreiben und malen. Ich wollte sie ausprobieren und einen Artikel darüber schreiben. Auf der Installationsseite werden Methoden für Debian/Ubuntu, Fedora/RHEL, Arch und Nix angeboten. Hier hätte ich Verweise auf die Distro-Repos oder auf Container-Formate (Snap, Flatpak, AppImage) erwartet. Stattdessen muss man die Software mit curl herunterladen, oder ein Repository des Projektes einbinden. Das ist der beste Weg, um sich Schadsoftware einzufangen.

Versteht mich nicht falsch. Ich habe nichts gegen das Projekt WayScriber und gehe nicht davon aus, dass sie Böses im Schilde führen. Es gibt tausende Beispiele für Linux-Projekte, die ihre Pakete unsachgemäss verbreiten. Ich selbst gehöre mit meinen Programmen auch dazu.

Die richtigen Paketquellen

Grundsätzlich sind die Repositories eurer Distribution der richtige Weg. Jede Distro hat eine Anwendung für das Verwalten von Anwendungen, den Paketmanager. Das können grafische Applikationen sein, oder auch Terminalbefehle. Meistens gibt es beides.

Moderne Paketmanager bieten neben den distributionsspezifischen Formaten auch Pakete aus anderen Quellen an. Häufig werden Flatpaks als alternatives Format angeboten. Bei Arch-basierten Distros gibt es meistens die Option, auch aus dem AUR-Repository zu installieren.

Hier ist meine Empfehlung:

1. Native Pakete aus den Repositories eurer Distribution verwenden (das ist der bevorzugte Weg).
2. Flatpaks verwenden, aber nur, wenn sie aus dem Flathub.org-Repo kommen.

Das war es! Von allem anderen rate ich dringend ab, als da wären:

• Snap-Pakete - Das ist ein Sonderweg von Canonical (Ubuntu), der eines Tages sterben wird.
• AppImages - Das ist kein Container-Format. Die Anwendungen werden nicht geprüft. Das ist wie Windows EXE.
• AUR - Das Arch User Repository ist als Malware-Schleuder bekannt. Verwendet das niemals.
• Installationsskripte - Davon rate ich dringend ab. Macht das niemals!

Wahrscheinlich gibt es noch weitere zweifelhafte Paketquellen, die mir nicht einfallen. Schreibt sie bitte in die Kommentare. Und ja, der Verzicht auf das AUR ist manchmal nicht möglich, z. B. bei der Installation von Druckertreibern.

Titelbild: https://pixabay.com/vectors/signage-prohibition-restriction-8856092/

Quellen: im Text