Finden Sie ein benötigtes Programm nicht in den OpenSuse-Repos, nutzen Sie einfach alternative Bezugsquellen wie Flatpaks oder kompilieren die Software selbst aus dem Quellcode.

Generell macht OpenSuse den Anwendern die Installation von Software leicht: Es genügt, das komfortable YaST-Modul Software zu öffnen (Abbildung 1) und dort nach dem gewünschten Paket zu suchen. Wer die Kommandozeile bevorzugt, dem steht via Zypper eine identische Funktionalität zur Verfügung.

Abbildung 1: Suchbegriff eingeben, Häkchen setzen, auf Übernehmen klicken: Bei mitgelieferten Paketen ist die Softwareinstallation einfach.

Doch die heile Welt endet für viele, wenn ein gewünschtes Programm nicht oder nur in einer veralteten Version in den Standard-Repositories liegt. Vor allem Windows-Umsteiger können oft gar nicht glauben, dass sich nicht jedes Programmpaket “für Linux” auf ihrem OpenSuse-System installieren lässt.

Inzwischen hat sich mit Flatpak [1] ein nicht distributionsgebundenes Linux-Paketformat verbreitet (Abbildung 2). Flatpaks lassen sich auf allen Linux-Derivaten unabhängig von deren Aktualität installieren – ähnlich wie Microsoft-MSI-Pakete unter Windows [2], die sich meist ebenfalls für mehrere Betriebssystemversionen einsetzen lassen.

Abbildung 2: Das Flatpak-Repository Flathub beinhaltet über 2500 Programme, grafisch ansprechend dargestellt und in Kategorien sortiert.

Trotzdem ist sichergestellt, dass Flatpak-Pakete nicht das System zerstören, indem sie für dessen Funktion notwendige Dateien überschreiben. Installierte Software lässt sich immer rückstandsfrei entfernen. Die meisten OpenSuse-Anwender dürften schon einmal Flatpaks auf ihrem System installiert haben. Die auf Flathub größtenteils topaktuellen Programmversionen und die einfache Installation mit Discover unter KDE oder dem Gnome-App-Store legen das nahe (Abbildung 3).

Abbildung 3: Sowohl der Software Store von KDE als auch der von Gnome unterstützen Flatpaks.

Offensichtliche Nachteile gibt es beim Ressourcenverbrauch: Flatpaks fallen wesentlich umfangreicher aus als normale Pakete, was Anwendern mit langsamer Internet-Anbindung längere Wartezeiten abnötigt. So umfasst die Installation des Videoeditors Kdenlive [2] als erstes auf dem System installiertes Flatpak-Paket 267 MByte, während YaST für dasselbe Programm nur rund 20 MByte herunterlädt. Nach dem Start belegt ein nativ installiertes Kdenlive rund 300 MByte RAM, ein als Flatpak eingebundenes dagegen rund 500 MByte Arbeitsspeicher.

Das heruntergeladene Paket enthält die KDE-Laufzeitumgebung für Flatpak (Abbildung 4), die nur bei der ersten Flatpak-Installation eines KDE-Programms installiert werden muss. Doch mit Ausnahme der geteilten Laufzeitumgebungen enthalten Flatpak-Pakete stets alle Abhängigkeiten eines Programms, da sie sich nicht auf vom System bereitgestellte Bibliotheken verlassen.

Abbildung 4: Zwei als Flatpak installierte Programme belegen inklusive der Laufzeitumgebungen nahezu 5 GByte Plattenplatz.

Im Gegensatz dazu dedupliziert die klassische Paketverwaltung die sogenannten Shared Libraries, also externe Bibliotheken mit Hilfsfunktionen, wie sie jedes moderne Computerprogramm nutzt, akribisch: Sie liegen genau einmal im System vor und werden nur einmal in den Arbeitsspeicher geladen, alle laufenden Programme können auf ihre Funktionen zugreifen.

Das ist einer der Gründe, warum Linux auf einem Rechner mit 4 MByte RAM und 50 MByte verfügbarem Festplattenplatz immer noch nutzbar bleibt. Der Nachteil dieses klassischen Systemansatzes: Jede Software muss für diesen distributionsspezifischen Versionsstand der Bibliotheken eigens kompiliert, also aus dem Quellcode übersetzt werden. Was Kompilieren bedeutet und warum es erforderlich ist, dazu später mehr.

Mit dem klassischen Linux-Paketverwaltungsansatz lassen sich Alltagsgeschäfte auf über zehn Jahre alter Hardware frustrationsfrei erledigen. Auf solchen PCs ist der Einsatz von ressourcenhungrigen Flatpaks nicht anzuraten. Wer jedoch auf durchschnittlichen Rechnern einige wenige Flatpak-basierte Programme gleichzeitig startet, während das restliche OpenSuse-System auf konventionellen RPM-Paketen basiert, dürfte in der Praxis kaum einen Unterschied bemerken.

Eine für alles

Die fehlende Deduplizierung der Bibliotheken bringt allerdings einen weiteren, nach Meinung vieler Kritiker schwerwiegenderen Nachteil mit sich: In klassischen Linux-Systemen genügt es, bei einer Sicherheitslücke genau die eine betroffene Komponente auszutauschen. Alle Programme, die die nun gepatchte Bibliothek nutzen, sind dann sicher. Es gibt verbreitete Bibliotheken, zum Beispiel zum Lesen von JPEG-Dateien, die viele Programme nutzen. Beim Einsatz von Flatpak dagegen gilt es, alle Programme aufzufrischen, die die anfällige Bibliothek nutzen.

Das allein wäre in der Praxis noch kein größeres Problem: KDE Discover, Gnome Software oder das entsprechende Kommandozeilenprogramm (sudo flatpak update) machen es leicht, alle Pakete zu aktualisieren, für die neuere Versionen vorliegen. Die Gretchenfrage lautet, ob man sich wie bei in Sicherheitsfragen erfahrenen Entwicklerteams der Linux-Distributionen darauf verlassen kann, dass jeder für ein Flatpak zuständige Softwareentwickler die erforderlichen Updates unverzüglich bereitstellt.

Bei den Autoren von Flatpak-Paketen handelt es sich in der Regel nicht um Distributionsentwickler, sondern meist um die Programmierer der enthaltenen Software. Das plattformübergreifende Paketformat bringt für sie den Vorteil, dass sie sich nur um ein einziges Paket für Linux kümmern müssen, statt um jeweils ein eigenes für alle gängigen Linux-Distributionen. Vor Flatpak stellten direkt nach einem neuen Release von den Programmentwicklern selbst bereitgestellte Pakete eine Ausnahme dar, heute stehen sie für viele gängige Programme auf dem zentralen Flatpak-Repository Flathub [3] bereit.

Flathub bietet inzwischen eine Verifizierung der Herkunft von Paketen von den originalen Programmautoren an (Abbildung 2, blauer Haken). Wer zahllose Stunden investiert, ein nützliches Programm zu schreiben, und es dann unter einer freien Lizenz kostenlos verteilt, der handelt wohl kaum aus arglistigen Motiven. Malware-Autoren möchten eher schnelles Geld verdienen.

Die Gefahr, dass ein Malware-Team ein Flatpak-Paket erstellt und auf Flathub hochlädt, das einen unter X11 mit Benutzerrechten trivial umsetzbaren Keylogger enthält, ist aber durchaus real: Jeder darf Pakete auf Flathub anbieten.

Schutzpanzer

Oft ist zu hören, per Flathub installierte Anwendungen seien sicherer als nativ installierte, weil Flatpak sie in eine Sandbox einsperrt. Tatsächlich stellt Flatpak eine technisch einwandfreie Abschottung auf der Basis von Bubblewrap [4] zur Verfügung, die Programme zuverlässig vom restlichen System separieren kann. Doch das nützt nichts, wenn die meisten Flatpak-Pakete dieses Sicherheits-Feature gar nicht nutzen. Die meisten Pakete auf Flathub tragen die Kennzeichnung potentiell unsicher (Abbildung 5), meist deswegen, weil sie schreibend auf das Home-Verzeichnis zugreifen können.

Abbildung 5: Die potenziell sichere Laufzeitumgebung von Flatpak wird unterminiert, wenn der Autor seinem Programm einen “full filesystem read/write access” gestattet, um Dateien zu öffnen und zu speichern.

Dass ein Programm Dateien im Home speichern darf, ist nicht per se ein Sicherheitsproblem. Jedoch könnte eine Anwendung damit ein Skript unter ~/.config/autostart/ ablegen, das beim Start der Desktop-Umgebung eine Schadsoftware ausführt. Tatsächlich benötigen Anwendungen keineswegs zwangsläufig Schreibzugriff, um Dateien zu speichern. Sie könnten stattdessen das sogenannte XDG Desktop Portal [5] nutzen, das den Schreibzugriff nur über für den Anwender sichtbare Speichern-unter-Dialogfelder gestattet. Mehr und mehr Programme tun das unabhängig von Flatpak, weil die Dialoge zum Öffnen und Speichern aus dem Desktop-Portal sich nahtlos in die Desktop-Umgebung einfügen.

KDE Plasma 6 startet standardmäßig eine Wayland-Sitzung, die ohne den altgedienten X-Server mit Wurzeln aus den 1980er-Jahren auskommt. Wayland schirmt laufende Anwendungen voneinander ab, Tastatureingaben erreichen nur noch das eine Programm mit Eingabefokus. Auch Plasma 5.27 aus Leap 15.5 bringt bereits eine ausgereifte Wayland-Unterstützung mit.

Linux rüstet sich sicherheitstechnisch also für eine Zukunft, in der Anwender Software aus vielen Quellen im Internet installieren und nicht mehr länger nur aus einem zentralen Repository, über das in Sachen Sicherheit ein für diese Aufgabe qualifiziertes Team der Linux-Distribution wacht.

Überhaupt gibt es unterschiedliche Ansichten darüber, welche konkrete Gefahr potenzielle Sicherheitslücken für einen durchschnittlichen Heimanwender darstellen. Ein häufiger Typ von Sicherheitslücken besteht darin, dass durch Programmierfehler Programmcode und Daten durcheinandergeraten (Abbildung 6). Dann kann man der Anwendung unter Umständen Schadcode in Form präparierter Daten unterschieben, die das Programm fehlerhafterweise ausführt.

Abbildung 6: In C und C++ überschreibt ein Zugriff auf nicht reservierte Array-Zellen ohne Fehlermeldung Speicher. Das lässt sich missbrauchen, um fehlerhaften Programmen eigenen Code unterzuschieben.

Um Rechner aus der Ferne anzugreifen, muss ein Angreifer die Lücken naturgemäß von außen triggern. Dass das oft über Webbrowser und E-Mail-Programme gelingt, liegt auf der Hand. Doch sobald Sie Dateien unbekannter Herkunft öffnen, kann das auch bei Textverarbeitungs- und Grafikprogrammen klappen. Hinter vielen feindlichen Übernahmen im Firmen- und Behördenbereich steckt ein unbedarfter Klick auf einen E-Mail-Anhang.

Ein Anfangsverdacht, dass eine Lücke vorliegen könnte, besteht, wenn ein Programm wegen eines Fehlers beim Speicherzugriff abstürzt. Was in der Praxis am effektivsten schützt, ist tatsächlich die große Heterogenität der Linux-Systeme. Ein konkreter Angriffsmechanismus funktioniert oft nur bei ein paar Tausend Rechnern weltweit – kein Vergleich zur typischen Anzahl verwundbarer Windows-Geräte.

Marke Eigenbau

Liegt ein Programm weder nativ noch als Flatpak für OpenSuse vor oder möchten Sie eine brandaktuelle Version ausprobieren, dann können Sie die Software selbst kompilieren, statt Pakete zu installieren, die es in bereits kompilierter Form enthalten. Kompilieren bezeichnet das Übersetzen aus dem menschenlesbaren Quellcode (Abbildung 7, links), in dem Entwickler ihre Software schreiben, in sogenannten Maschinencode (Abbildung 7, rechts), den die CPU versteht.

Abbildung 7: Der C-Code (links) ist eindeutig lesbarer als die hexadezimalen Zahlenfolgen der daraus kompilierten ausführbaren Datei (rechts).

Es ist ineffizient und praktisch nicht mehr üblich, Maschinencode direkt zu schreiben. Die meist in C oder C++ geschriebenen Desktop-Programme müssen also kompiliert werden, bevor Sie das Programm starten können. Bei den normalen Programmpaketen nehmen Ihnen die OpenSuse-Entwickler (native OpenSuse-Pakete) oder die Programmautoren (Flatpak-Pakete) diese Arbeit ab; der Quellcode des Programms braucht Sie dann nicht zu interessieren.

Möchten Sie das Kompilieren hingegen selbst übernehmen, benötigen Sie zunächst eben diese sogenannten Sourcen. Viele Projekte bieten ihren Quellcode als Tar-Archiv zum Herunterladen an oder stellen ihn auf Github (Abbildung 8) oder ähnlichen auf der Versionsverwaltung Git [6] basierenden Online-Diensten bereit.

Abbildung 8: Wer das Paket git installiert, kommt mit der auf Hosting-Plattformen unter Code genannten URL an den Quellcode.

Eine Versionsverwaltung ist eine Software, die den Änderungsverlauf des Quellcodes dokumentiert. Für unsere Zwecke ist nur relevant, wie Sie diesen Systemen den Quellcode entlocken. Das geht ganz einfach: Nach Installation des Pakets git tippen Sie auf der Konsole git clone und fügen die HTTPS-URL ein, die Ihnen der Software-Hoster über Buttons wie Code, Clone oder Checkout anbietet. So entsteht ein Unterverzeichnis mit dem Quellcode, genau wie nach Entpacken eines Tarballs.

Außerdem müssen Sie einen Compiler für C/C++ sowie einige weitere Programme installieren, die Sie in YaST Software über das Schema C/C++-Entwicklung auswählen. Zusätzlich sollten Sie gleich noch das Paket cmake einspielen, das aufgrund seiner Verbreitung eigentlich im Schema C/C++-Entwicklung enthalten sein sollte.

Der Kompiliervorgang umfasst drei Schritte: Zuerst ermittelt ein Konfigurationslauf die Speicherorte der für das Kompilieren benötigten Dateien auf Ihrem System (Abbildung 9). Dann folgt das eigentliche Kompilieren, das einige Zeit dauert. Der letzte Schritt installiert die kompilierten Dateien in die Systempartition, damit Sie die Software mit dem Aufruf des Programmnamens auf der Konsole starten können (Abbildung 10).

Abbildung 9: Findet das configure-Skript alle erforderlichen Abhängigkeiten, dann meldet es gegen Ende creating Makefile.

Abbildung 10: Der letzte Schritt von make-install geht meist schnell. Das hier eingeschobene DESTDIR=/tmp installiert die Software nach /tmp, um zu prüfen, ob make install wichtige Dateien überschreibt.

Wechseln Sie also mit cd Programm in das Quellcodeverzeichnis und sehen Sie sich dessen Inhalt per ls oder in einem grafischen Dateimanager an. Für die erwähnten drei Schritte ist ein sogenanntes Build-System zuständig. Es gibt eine Handvoll verbreiteter Systeme, die sich alle in der Bedienung unterscheiden (siehe Tabelle “Gängige Build-Systeme”).

Systemfrage

Vorab müssen Sie herausfinden, welches dieser Build-Systeme der gewünschte Quellcode nutzt (Abbildung 11). Zum Glück ist jedes am Vorhandensein einer einzigen charakteristischen Datei zu erkennen: Liegt im Basisverzeichnis des Quellcodes ein Skript mit dem Namen configure oder auch autogen.sh, dann liegt das Build-System GNU Autotools [7] vor.

Abbildung 11: Hier liegt, erkennbar am Skript configure, das Build-System Autotools vor. Der Programmautor hat autogen.sh aufgerufen, um configure zu erzeugen, und autogen.sh nicht gelöscht.

Falls Sie die Datei autogen.sh vorfinden, nicht jedoch configure, dann führen Sie dieses Skript zuerst aus (./autogen.sh), was die Datei configure erzeugt. Rufen Sie sie mit ./configure auf, dann scannt das Skript Ihr System nach den für die Software erforderlichen Abhängigkeiten, was im Erfolgsfall in Ausgaben wie checking for xxx ... yes resultiert.

Findet Configure dagegen eine benötigte Abhängigkeit nicht, endet die Zeile mit no, und es folgt eine abschließende Meldung configure: error: Package requirements <Name> were not met oder ähnlich. (Abbildung 12).

Abbildung 12: Bei der ersten fehlenden Abhängigkeit stoppt das Skript configure mit einer Fehlermeldung.

Nervig ist an dem uralten, noch aus den 80er-Jahren des vorigen Jahrhunderts stammenden Autotools-Build-System, dass Configure immer gleich bei der ersten fehlenden Abhängigkeit abbricht. Installieren Sie sie nach, folgt möglicherweise der nächste Abbruch und eine weitere Meldung zu einer fehlenden Abhängigkeit. Dieser Zyklus aus configure-Aufrufen, Abbrüchen und der Installation fehlender Abhängigkeiten kann sich etliche Male wiederholen.

Sehen Sie die abschließende Meldung [...] creating Makefile, beginnt das eigentliche Kompilieren. Als Basis dafür hat Configure die Datei Makefile erstellt, eine Art Makro für in der Regel Hunderte Compiler-Aufrufe, die die ebenso zahlreichen Quellcodedateien mit der Endung .c oder .cpp in ausführbare Programme umwandeln (Abbildung 13). Sie brauchen dazu auf der Kommandozeile nur make -j 8 aus dem Quellcodeverzeichnis aufzurufen. Die Zahl hinter der Option -j sollte dabei der Anzahl der Prozessorkerne in Ihrem Rechner entsprechen.

Abbildung 13: Für jede .cpp-Datei im Quellcode einer Anwendung erfolgt ein eigener Compiler-Aufruf. Die Header-Dateien (.hpp-Dateien) fungieren als Bindeglieder für eine einzige ausführbare Datei.

Die Vielzahl der Aufrufe und die vom aufgerufenen Tool zurückgegebenen Meldungen dürfen Sie getrost ignorieren, solange sie weiter über den Bildschirm laufen. Wenn der Vorgang endet, ohne dass die Worte Fehler oder error erscheinen, hat das Kompilieren geklappt. Tauchen sie dagegen so wie in Abbildung 14 auf, dann ist der Kompiliervorgang fehlgeschlagen, auch wenn er eventuell noch eine Weile weiterläuft.

Abbildung 14: Der erste Fehler stoppt das Kompilieren, auch wenn andere Threads noch weiterlaufen.

Es gibt allerdings viele Gründe, warum er scheitern kann – zu viele, um sie hier alle aufzulisten. Am häufigsten liegt es daran, dass das Kompilieren die Hunderte interne Aufrufe externer Bibliotheksfunktionen aus den systemweit installierten Bibliotheken vornimmt. Das testen Programmautoren oft nur für ihr eigenes oder wenige weitere Systeme: Es gibt einfach zu viele Linux-Distributionen für einen umfassenden Check.

Doch oft findet sich im Internet Hilfe. Da Problembeschreibungen und -lösungen zum größten Teil in englischer Sprache vorliegen, schalten Sie zuerst die Fehlerausgabe mit export LC_ALL=C auf Englisch und starten den Make-Vorgang erneut. So können Sie per Copy & Paste direkt nach den Fehlermeldungen suchen.

Viele Programme nutzen heute nicht mehr die uralten Autotools, sondern das modernere Build-System Cmake [8]. Sie erkennen es an der Präsenz der Datei CmakeLists. In dem Fall rufen Sie statt des nicht vorhandenen configure-Skripts aus dem Quellcodeverzeichnis heraus das Kommando cmake . auf. Der Punkt hinter cmake verweist auf das aktuelle Verzeichnis und darf nicht fehlen. Auch für Cmake-basierte Software lautet der Aufruf für den zweiten Schritt, das eigentliche Kompilieren, make -j CPU-Cores.

Installation

Sowohl bei Autotools- als auch Cmake-basierten Softwareprojekten folgt nun als dritter Befehlsaufruf, der das kompilierte Programm auf dem System einrichtet, sudo make install. Die Entsprechung bei anderen Build-Systemen entnehmen Sie der Tabelle “Gängige Build-Systeme”. Gewöhnlich kopiert der Aufruf die ausführbare Programmdatei nach /usr/local/bin/, weswegen er Root-Rechte erfordert. Danach sollten Sie das Programm auf der Kommandozeile durch Aufruf des Programmnamens (typischerweise in Kleinbuchstaben) starten können.

Oft, aber nicht immer funktioniert der Aufruf sudo make uninstall, um ein installiertes Programm wieder aus dem System zu entfernen. Sowohl die install– als auch die uninstall-Vorgänge gehen dabei kursorisch vor: Sie kopieren oder löschen eine vorgegebene Dateinamensliste. Bei Namenskollisionen mit anderen Programmen sind Probleme vorprogrammiert. Deshalb gilt das Installieren per Paket, sei es als Flatpak oder als natives OpenSuse-Paket, als deutlich risikofreier als der Aufruf von sudo make install. Anzuraten ist das Kompilieren daher nur, wenn sich absolut kein Programmpaket greifen lässt. Das kommt den distributionsagnostischen Flatpaks zum Dank immer seltener vor.

Bei fertig installierbaren Pakten haben Ihnen andere den fehleranfälligen Vorgang des Kompilierens schon abgenommen. Außerdem stellen die Paketsysteme RPM und Flatpak verlässlich sicher, dass die Installation keine bestehenden Dateien überschreibt. Jede einzelne eingespielte Datei ist entweder registriert (RPM) oder in einem gesonderten Unterverzeichnis isoliert (Flatpak). Daher funktioniert auch die Deinstallation verlässlich.

Fazit

Erste Wahl bleibt für OpenSuse, Software über das YaST-Modul Software aus den Repositories der Distribution zu installieren – damit erhalten Sie getestete Programmpakete. Allerdings sind ältere Versionen aus den OpenSuse-Leap-Repos nicht immer stabiler als neuere: Schließlich bemühen sich die Entwickler kontinuierlich, Fehler auszubügeln.

Generell konnte OpenSuse bei der Anzahl der verfügbaren Pakete nie mit Debian konkurrieren. Die gut 2500 distributionsübergreifenden Programme, die im auch unter OpenSuse mittlerweile ab Werk eingebundenen Flathub-Repository [3] vorliegen, relativieren diesen Nachteil. Viele Softwareentwickler stellen inzwischen gleich beim Erscheinen einer neuen Fassung ihrer Software dort ein Paket bereit.

Möchten Sie die neuesten Entwicklungen einer Software begutachten, die noch nicht in einer stabilen Ausgabe erschienen ist, besorgen Sie sich den Quellcode aus den Online-Repositories auf Github oder vergleichbaren Plattformen und kompilieren ihn selbst. (uba)