Was haltet ihr von alternativen Paketformaten wie Flatpak, AppImage oder Snap? Nutzt ihr sie häufig oder lehnt ihr sie kategorisch ab? Was sind die Vor- und Nachteile der einzelnen Lösungen? Wie setzt ihr sie ein? Und vielleicht die wichtigste aller Fragen: Liegt dort die Zukunft der Softwareverteilung in Linux?
Ich persönlich probiere schon aus beruflicher Neugier alles Neue aus, was nur halbwegs verspricht, Hand und Fuß zu haben und meine Rechner nicht zur Explosion bringt. So war ich auch früh dabei, Flatpak und Snap auszuprobieren und darüber zu schreiben.
Schnappi disqualifiziert
Canonicals Snap habe ich dann schnell wieder aufgegeben, da der Ubuntu-Distributor damit mal wieder einen Sonderweg einschlägt, von dem man nicht weiß, wann er wieder eingestellt wird. Zudem hat der einzige offizielle Store ein proprietäres Backend, was mir nicht in den Kram passt. AppImage habe ich seit Jahren gelegentlich verwendet, allerdings hat die Plattform erst durch die Verbreitung von Flatpak und Snap an Attraktivität und Präsenz gewonnen.
Vor- und Nachteile
Da sich meine Verwendung hauptsächlich auf Flatpak reduziert hat, hier einmal die von mir wahrgenommenen oder vermeintlichen Vor- und Nachteile
Vorteile:
- aktuelle Software-Versionen
- mehrere Versionen einer Software nebeneinander möglich
- in den Distributionen nicht verfügbare Pakete verfügbar
- Distro-agnostisch einsetzbar
- Sandboxed
Nachteile:
- Sicherheitskonzept noch nicht ganz ausgereift
- Berechtigungssystem noch nicht ganz ausgereift
- benötigt mehr Platz auf dem Speichermedium
- nur auf dem Desktop einsetzbar
- Job des Paket-Maintainers wird langfristig überflüssig
Raum für Diskussion
Die von mir aufgezählten Vorteile sind, wie ich meine, unbestritten. Bei den notierten Nachteilen ist für mich der Mehrbedarf an Platz auf dem Speichermedium nicht wirklich einer. Er relativiert sich, wenn man die nötigen Runtimes einmal installiert hat. Ich denke, die Abneigung erwächst hier eher ideologisch aus dem Gedanken, dass man Bloat nicht unterstützen will. Die Berechtigungen von Flatpaks lassen sich mit Flatseal grafisch manipulieren.
Paketbetreuer ade
Was mich bei künftig zu erwartender weiterer Verbreitung wirklich stört, ist der vorhersehbare Wegfall des Paketbetreuers in den jeweiligen Distributionen. Diese Enthusiasten stehen zwischen Entwicklern im Upstream und den Nutzern und erfüllen dort eine technische und soziale Rolle, die ich als wichtig für das Miteinander erachte. Andererseits erleichtern die neuen Paketsysteme die Arbeit der Entwickler. Sie müssen nur noch ein Paket schnüren, das in allen Distributionen funktioniert, wo das jeweilige Framework installierbar ist. Noch universeller ist AppImage, das keinerlei vorherige Installation voraussetzt.
Wie sieht die Zukunft aus
Flatpak wird in der Linux-Community bevorzugt und scheint bei den Desktop-Usern unter den alternativen Paketformaten das Rennen zu machen. Unternehmen wie Red Hat und vermehrt SUSE bauen Flatpak fest in die Pläne für die zukünftige Gestaltung ihrer Distributionen ein. Fedora wird vielleicht schon im nächsten Jahr das Konzept von Silverblue auf Fedora Workstation umsetzen und auf einen Mix von Flatpak für grafische Anwendungen und Toolbox für die kleinen Helferlein setzen. Bei openSUSE könnte der Einschnitt mit ALP noch etwas radikaler ausfallen.
Wie steht ihr zu den neuen Paketformaten und der ihnen zugewiesenen Rolle für die Ausgestaltung künftiger Distributionen?
Foto: Jiawei Zhao on Unsplash
Snap war der Grund, dass ich mich endgültig von Ubuntu verabschiedet habe. Kurze Zeit mit Manjaro unterwegs, bin ich mittlerweile mit Fedora sehr zufrieden. Flatpak nutze ich hier für eine einzige Software: Obsidian (Notizen-App). Auch nutze ich zusätzliche Repos: RPM Fusion, Google und Insync.
Für mich als Admin vieler Arbeitsgeräte mit Linux im produktiven Einsatz sind ist jeder Ansatz die Hölle. Egal ob SNAP, Flat oder AppImage.
Es gibt dadurch keinerlei Kontrolle mehr welche Software auf diesen Geräte läuft. Auch wenn administrative Dinge ausgeschlossen sind (durch fehlenden Root-Zugang) sind dadurch die Systeme nicht mehr alle gleich.
Im Regelfall stören die Userspace-Programme nicht bei Updates von mir, aber ich will nicht wissen was passiert bei einer Lücke in diesen Dingern… willkommen in der Windows-Welt.
Aus dem Grund werden von mir nachträglich immer sämtliche Frameworks entfernt und IP-Adresse der entsprechenden Hubs gesperrt.
Ich bin ein extremer verfechter der zentralen Verwaltung jeglicher Software und entsprechender Kontrollinstanz.
Ich würde mir zumindest ein policyD-Kit für diese Frameworks wünschen worüber die Rechte eingeschränkt sind und wieder eine zentrale Rechte-Verwaltung möglich ist.
Mich würde interessieren welche Distributionen ihr nutzt (Firma, Behörde, …?) und zu welchem Einsatzzweck (Desktop Rechner, …?)?
Gemischt ^^
Debian, Ubuntu, Arch sind die Platzhirsche. Und sind im privaten Sektor (Schwerpunkt IT) angesiedelt.
Server und Desktop wird genutzt. Gerade die Desktop-Umgebungen haben den Sch**** vorinstalliert und wird bei der Einrichtung direkt entfernt.
Danke
Ich bin auch seit ca. 20 Jahren mit Linux unterwegs und handhabe das Meiste über apt-get und .deb-Pakete unter inzwischen Xubuntu (Start waren aber SuSe und andere). Eine besondere Rolle hat AppImage in jüngster Zeit eingenommen: Ich nutze es für ein paar Programme in verschiedenen Versionen oder aus anderen Gründen als Pendant zu portable Apps unter Windows, v.a. weil keine Abhängigkeiten bestehen. Funktionierte bislang tadellos.
Snap habe ich mehrfach probiert und ich stelle diverse Probleme fest (u.a. Zeitverzögerungen, keine flüssige Bildausgabe, usw.) Nutze ich nicht mehr.
Flatpak klingt immer wieder interessant, aber ich habe es noch nicht ausprobiert.
Also ich bin seit LST Linux 1994 im Linuxbereich und war auch schon bei Debian und mit eigener kleiner Distro.
Flatpack und consorten kann ich nichts abgewinnen.
Das Zeug fliegt bei mir sofort vom Rechner.
Mir alles zu unsicher.
Bei mir läuft auf allen Geräten Debian stable und die meisten Applikationen kommen als flatpak. Ich schmeiße auch vorinstallierte Anwendungen wie Thunderbird erst einmal raus und ersetze sie durch flatpaks. Grund für diese Vorgehensweise ist hauptsächlich Neugier auf neue Features und Entwicklungen.
Ansonsten probiere ich gerne alles mögliche in VMs (fedora, solus budgie, kde neon, gnome nightly … ), aber nicht im Produktivsystem.
Snaps gehen mir aus oben genannten Gründen auch ziemlich gegen den Strich. Wenn ich mal Ubuntu für jemanden installiere, deaktiviere ich das Snapstore. Das geht ja zum Glück recht einfach.
Warum stand denn im Artikel, dass flatpaks nur auf dem Desktop laufen … ?
Naja, es gibt halt wenige fürs Terminal. Snap hat da mehr zu bieten. das liegt aber an der generellen Ausrichtung, die bei Snap mehr in Richtung IoT und Container geht und bei Flatpak mehr auf den Desktop abzielt.
Also Flatpak finde ich nicht Schlecht nutze es auch bei Programmen Regelmässig, Snaps hat mir von daher nicht gefallen weil Canonical das alleinige sagen hat.
Klar müsste da noch Nachgebessert werden die sollten das machen das die Paketersteller sich Registrieren müssen um Sicherzustellen wenn was ist wer genau das Paket erstellt hat um mehr Sicherheit zu Gewährleisten das ist das Einzige was ich bei Flatpak ändern würde.
Das die Pakete größer sind weil alle Libaries mit drin sind ist mir Persönlich Egal heute hat doch eh jeder Festplatten um die 500 GB als System Partition da ist Platz genug und mit MBit Leitungen fällt es eh nicht auf ob du da nun 200 oder 500 MB runterlädst.
Ich kann keine der vermeintlichen Vorteile für mich positiv verbuchen. Jedes Programm bringt seinen unkontrollierten Sack voll eigener Libs mit. Sicherheitskonzepte der Distributionen werden ausgehebelt.Nicht mein Weg. Wäre für mich ein Grund, der Distro meines Vertrauens den Rücken zu kehren, falls dort dieses Konzept Einzug halten sollte.
Genau das denke ich auch. Das erinnert mich an Windows, als die einzeln zusammengesuchten Programme alle ihre eigenen Libs mitbrachten und daher zigmal vertreten waren und den Rechner zumüllten. Mit dem Plattenplatz war es damals auch noch nicht so weit her. Sicher ist das heute nicht mehr so, aber einen Vorteil sehe ich nicht.
Ich kann bei z.B. Debian stable die Backports nutzen, oder direkt ein Sid bzw. eine Rolling Release Distro wie Arch einsetzen. Alles ist aber aus den Repos und vermittelt mir mehr Sicherheit als von irgendwelchen Fremdrepos, wo ich nicht genau weiß, wer dahinter steckt.
Außerdem kann ich schnell eine VM aufsetzen, auch da habe ich mehrere Möglichkeiten.
Zusammengefaßt: ich mag es nicht.
Na ja, sag ich ja mit den Backports. Nicht optimal, aber geht.
Ich bin in Summe bei dir!
Du hast ein paar Systeme vergessen.
Snap ist bei mir gestorben, weil ausser Canonical keiner der Anbieter sein kann. Es gibt eine alternative Provider Entwicklung, aber das wird Canonical bei Ubuntu nie erlauben, dass sich das ersetzt auf installationswunsch. Ausserdem mag ich nicht, dass es mir df/mount vollkotzt, aber das könnte man durch Patching der Tools lösen.
Flatpak ist auch mein alternatives Lieblingsformat aber nicht ganz so unabhängig vom Host, wie die Leute immer behaupten. Versuch mal Teamviewer zu paketieren. Das failed wegen $komischenAssemblerInstruktionen, genauso wie bei Adobe Acrobat. Ausserdem wenn dein Flatpak zu alt ist, und neue Entwicklungen im FreeDesktopStandard kamen, viel Spass mit deinem alten Flatpak und neuen Applikationen. Aber es erlaubt uns mehr Freiheit beim Nutzen direkt vom Anbieter. Maintainer, die nicht automatisch Upstream sind, werden wir allerding trotzdem brauchen. Maintainer sind eine Reviewinstanz, die man nicht missen mag.
Der Vorteil von Flatpak ist beim Freedesktop Standard auch, dass ein Filepickersystem wie bei Android vorangetrieben (werden) wird, damit kein Overlaysystem passieren kann. Wir haben Berechtigungen(oder werden haben), die das System wesentlich sicherer machen als wenn man nur klassisch Dateien aufs System liegt und die kümmern sich drum (siehe deb und rpm). Apparmor und SELinux haben sich nie durchgesetzt, deshalb ist meine Hoffnung zum Absichern des LinuxDesktops momentan Flatpak & FreeDesktopStandards. Das kann sich natürlich weiterentwickeln
Appimage ist sehr vielversprechend (hab aber auch noch nie mit Acrobat oder Teamviewer das versucht), hat aber (wie auch Flatpak) das Problem, dass sie sich schwertun, Converter zu schreiben… Wenn man für gradle oder debian pakete ein gesamt paket erstellen will, wirds schnell sehr viel handarbeit, aber wie gesagt, flatpak hat da ähnliche probleme.
Was das viel grössere Problem bei Appimage is: Es setzt sich keine Provider/RepositorySoftware durch, die sich um das Update von Software kümmert. Und das bricht einem auf lange Sicht das Genick, weil man sich nicht drum kümmert und irgendwann vulnerable oder kaputte Software am System hat. Aber für Anbieter die nur zeigen wollen, “hey, geht auf linux” ist es natürlich nice.
Persönlich brauche ich diese Formate nicht. Mit arch linux + AUR nutze ich eine Distribution die meine Vorliebe zu neuer Software befriedigt und bisher auch alle Pakete geliefert hat, die ich jemals benötigt habe. KeePassXC liegt bei arch linux in der Version 2.7.1 vor.
Ob es ein Vorteil ist, wenn alles in einer Sandbox läuft?
Nicht unbedingt, jedenfalls dann nicht wenn das librewolf flatpak nicht mit KeePassXC kommunizieren mag.
Fedora hat neben Flathub ein eigenes Flatpak-Repo und auch SUSE wird möglicherweise ein eigenes Flatpak-Repo haben. Einerseits aus rechtlichen Gründen (Codecs etc.), andererseits damit die Flatpaks optimal auf das System abgestimmt sind. Es wird also weiterhin Paketbetreuer geben. Auch Snaps von Canonical werden oftmals von den Ubuntu-Entwicklern betreut, nicht von den ursprünglichen Entwicklern.
Ich nutze momentan Ubuntu 22.04 LTS mit Snaps. Ich habe mich entschieden alle nicht GNOME-Programme als Snap zu installieren, da das System dadurch einfach sauberer ist. Ich nutze GIMP2 (GTK2), VLC, Krita, Zoom und Telegram als Snap. Ich kann diese damit rückstandslos entfernen und erspare mir ein Chaos von hunderten Abhängigkeiten. Vorteil von Snaps gegenüber Flathub ist die bessere Berechtigungsverwaltung und das sie ohne Probleme auch ohne Desktop funktionieren. Nachteil von Snaps ist, dass sie momentan an Canonicals Snap Store gebunden sind.
Das Basissystem (KDE/Gnome-Anwendungen) sollte meiner Meinung nach auf RPM/APT setzen, alles was darüber hinausgeht gern als Snap/Flatpak.
OpenSuSE zumindest hat kein dediziertes Flatpack repo und verwendet unter KDE in Discover verwendet den standard flathub.
Bei Tumbleweed braucht man zwar sehr selten Flatpack Pakete, kann aber dann doch die Installation aus einem zusätzlichen repository verhindern. Das ist sehr angenehm, da viele manuell hinzugefügte repos die Wahrscheinlichkeit erhöhen das die Paketverwaltung bei einem update nicht automatisch die Abhängigkeiten auflösen kann.
Wenn man die Diskussionen in den Mailinglisten zu SUSE ALP verfolgt, ist dort wohl geplant ein eigenes Flatpak-Repo auf die Beine zu stellen. Im Unternehmensbereich hat man gar keine Wahl, da kann man sich nicht auf einen fremden Anbieter wie Flathub verlassen, wo man keinerlei Kontrolle über die Pakete und Updates hat.
ALP ist ja noch mal was anderes und auch noch alpha.
Aktuell sind da aber noch die Standard (Tumbleweed?) Repos drin und man kann Flatpak von flathub via Discover nachinstallieren. Zumindest im aktuellen boild von ALP/MircroOS.
Denke im Unternehmensumfeld (oder paranoiden Benutzern wie mir) ist auch zwingend erforderlich, dass einer die Pakete Signiert hat, dem man vertraut. Alle standard Repos sind ja mit den openSUSE GnuPG Key signiert. Bei Flatpak bin ich mir nicht sicher ob es überhaupt jemanden gibt die die Richtigkeit der Quellen prüft und auch zumindest grob die Sicherheit (also das es keine Malware oder ähnliches ist) prüft. Übrigens ein großes Manko von Flatpak aus meiner Sicht, dass es keine solche Prüfung gibt, die normalerweise der Maintainer unter Aufsicht des Technischen Leiters macht!
Flatpaks direkt vom Hersteller selber, wie Firefox und Thunderbird oder Joplin, Libreoffice. Das sicherste was man tun kann. Aber jeder wie er meint.
Das sehe ich genau umgekehrt. Die freiwillige Selbstkontrolle klappt nicht. Es muss immer eine unabhängige Zwischeninstanz geben.
Ich bin ziemlich begeistert von den Container-Apps. Egal welches Format man bevorzugt: Wenn du eine App ausprobieren willst, installerst Du sie als Container-App. Wenn Sie das tut was Du erwartest ist gut. Wenn nicht, entsorgst Du sie rückstandfrei, auch alles gut.
Da ich vorwiegend auf Ubuntu setze, ist naheliegend SNAP das bevorzugte Format für meine App-Container. Kein anderes Format ist so perfekt und geschmeidig in Ubuntu integriert. Zudem kann SNAP nicht nur Desktop-APP sondern auch Server-APP. Bei FLAT und AppImage wird die Luft da schnell dünn. Aus technischer Sicht halte ich SNAP für überlegen. Insbesondere durch die Verwendung von SquashFS und der permanenten Komprimierung des Images. An FLAT stört mich eine Entwicklung besonders: Die haben tatsächlich die Möglichkeit von geshareten Libraries in der Laufzeit eingebaut, WTF…? Das Kernproblem welches man lösen wollte… kaputt geflickt. HaHaHa.
AppImage und FLAT verwende ich nur wenn es kein entsprechendes SNAP Packet gibt oder nur ein veraltetes. Das ist übrigens ein Problem aller Formate: Wird ein Paket nicht maintained, ist es halt schnell veraltet. So gesehen hat Ferdinand meiner Meinung nach unrecht: Maintainer werden nicht überflüssig. Aber ihr Job wird sich verändern.
Auch bei weiteren Argumentationen des Autors bin ich andererer Meinung: SNAP ist kein Sonderweg. Es ist ein weiterer Vorschlag für kontaineriserte Apps. Es sei denn man würde auch Systemd oder AppImage und änliche Entwicklungen als Sonderweg ansehen. Systemd war mal unbedeutend und AppImage war immer unbedeutend. (NB: SNAP war vor FLAT, also wäre dann FLAT der Sonderweg). Meiner Meinung nach wird die Frage nach dem richtigen APP-Container Format beantwortet durch den Verwendungs Entscheid welche Distri man verwenden will. Wenn Du mit Fedora glücklich bist, wirst Du eher mit FLAT glücklich sein.
Wenn Du mit Ubuntu glücklich bist, wirst Du eher mit SNAP ans Ziel kommen.
Wenn Du mit SUSE glücklich bist, kommt es nicht darauf an weil Du die meiste Zeit für einen schöneren Desktop verbrennst 😉
> An FLAT stört mich eine Entwicklung besonders: Die haben tatsächlich die Möglichkeit von geshareten Libraries in der Laufzeit eingebaut, WTF…? Das Kernproblem welches man lösen wollte… kaputt geflickt. HaHaHa.
Was meinst du damit? Was ist das Problem bei Shared Libraries?
Wegen Serversoftware: Da kann man auch einfach klassische Docker/LXC Container einsetzen, mir ist da der Vorteil von Snap nicth klar, ich sehe nicht, wo das sicherer sein sollte als Flatpak. Kannst du das erläutern?
> Wenn Du mit SUSE glücklich bist, kommt es nicht darauf an weil Du die meiste Zeit für einen schöneren Desktop verbrennst 😉
Was meinst du damit?
> Shared Libraries durchbrechen das “single use” Konzept. Die Library-Hell ist zurück!
Also, ich habe keine Library Hell mit Debian, SUSE oder auch NixOS (da noch viel weniger…)
Wenn du nicht auf das Problem anspielst, dass du eine Applikation nicht updaten kannst, weil es für die Library keine neuere Version gibt, aber die Applikation das braucht und eine Sicherheitslücke hat, dann weiss ich wirklich nicht, was das Problem ist. Oder du unterschiedliche Versionen der gleichen Library installieren willst.
Ganz ehrlich, ich kenne die DLL Hell, aber von einer “Library Hell” hab ich noch nicht gehört, was meinst du?
> Snapstore stellt ziemlich viele Server-Apps zur Verfügung Flat und AppImage eher weniger.
Ja, weil Flatpak dafür nicht gemacht ist. Bei Appimage war das Konzept imho auch ein anderes. Für Server”Apps” hast du Docker container.
> Snap wurde ursprünglich für Serveranwendungen bzw für IOT / Edge-Computing geschaffen. Natürlich kann man auch selber mit Docker / LXC (ich habe recht viele Services in LXC). Aber manchmal ist es einfacher eine fertige App (SNAP) hin zu stellen.
Ja, und auf hub.docker.com finde ich garantiert mehr services, als du in Snap 😀 😉
Und ich weiss nicht, was an einem Snap einfacher sein soll als bei einem Docker container. Den ich nicht nur von Ubuntu laden kann, sondern auch von woanders.
> Ich habe übrigens nicht behauptet das SNAP sicherer ist als die Konkurenz. Ich bin aber der Meinung das SNAP konzeptionell und technisch Vorteile hat gegenüber FLAT und sowieso gegenüber AppImage.
Und die da wären deiner Meinung nach? Ich kann das tatsächlich nicht erkennen, ausser das Snap auch Services und nicht nur Desktop Apps abfrühstücken könnte.
Du hängst Dich aber ganz ordentlich rein. Ferdinand hat diesen Artikel als Meinungsartikel deklariert (das ist sehr anders als eine Recherche). Und er hat die Leser um ihre Meinung gebeten. Ich habe den Eindruck Deine Meinung ist auch die einzige Wahrheit. Wenn Du nochmals (oder einmal richtig) meinen ursprünglichen Kommentar liest, wirst Du sehen das ich den übrigen Teilnehmern ihre eigene Meinung zubillige.
Es geht nicht um meine Meinung. Es klingt halt so, als hätte für dich Snap Vorteile ausser dass es auch headless Services kann und das du aus $Gründen die Architektur von Snap besser findest. Und das hätte ich halt ganz gerne eine ordentliche begründung.
Wer weiss, vielleicht habe ich ja schlicht was übersehen in meiner Beurteilung.
Als Anwender ist mir erstmal egal auf welchen Weg ein Programm den Weg zu mir findet. Welches Paketsystem nun das regelt ist egal, wenn es läuft und gut ist. Fertig.
Andereseits welches Paketsystem oder vielleicht auch mehrere Paketsysteme zusammen bieten das beste? Was mache ich? Als Debian Nutzer, das klassische Paketsystem mit Fremdquellen und Appimage. Ich muß aber zugeben das ich noch nicht so tief in die Materie eingestiegen bin
jetzt auf die schnelle ein für und wieder für das eine oder Paketsystem zu schreiben. Man hat eine Nutzung aus alter Gewohnheit. Im Moment verfolge ich das zwar und warte weiter ab. Wenn ich jetzt in die Situation komme das ich z.b. ein Anwendung benötige die es nicht in den Debian Quellen gibt
werde ich das bewerten müssen.
Egal was auf deinem Rechner passiert? Na, wenn du da mal bei Linux nicht an der falschen Stelle bist!
Nicht egal was auf meinen Rechner passiert. Mein Egal bezieht sich auf die Möglickeit zwischen verschiedenen vertrauenswürden Quellen zu wählen. Wenn ich verschiedene Möglichkeiten habe die ich alle als gleich sicher betrachte ist mir egal ob ich ein apt install oder flatpack install eintippe.
Jetzt kommen wir sicher zu der spannenden Frage ob ein apt install sicherer ist als ein flatpack install.
Ja, ich glaube die Frage werden wir hier wohl nicht klären. Jeder hat da so seine eigene Theorie. Ich finde das grundsätzlich eine spannende Entwicklung. Bis auf weiteres werde ich die original DEB Pakete einem Appimage oder Flatpak oder was auch immer vorziehen. Ich halte das für konsistenter. Nur wenn ich das nicht vermeiden kann (eigene Abwägung!), dann werde ich etwas abweichendes nutzen. Trotzdem ist diese Entwicklung wichtig (s. mein Post). Es bleibt spannend.
Ich sehe noch weitere Nachteile:
Fazit: Für mich sind Flatpaks nur eine Notlösung, falls es kein natives Paket gibt und die Software auch nicht mit vertretbarem Aufwand selbst aus den Quellen kompiliert werden kann. Native Pakete sind in fast allen Belangen Flatpaks überlegen.
> Benötigt nicht nur mehr Plattenplatz, sondern allgemein mehr Ressourcen (RAM, CPU).
> …
> Flatpoaks sind damit auch langsamer
Da zeigst du mir bitte Benchmarks, sonst halte ich das für FUD.
> Wer überprüft Flatpak-Pakete? Nicht immer ist der Software-Autor der Paketersteller, böswillige Personen könnten leicht Malware-verseuchte Pakete einschleusen
Das Problem hast du immer. Bei Upstream Paketen, wie auch wenn Maintainer dazwischen hocken. Wo ist das ein Problem bei Flatpak oder Snap?
Die Struktur mit Maintainern hat sich über die Jahrzehnte als sehr sicher herausgestellt.
Die Maintainer sind zur Kontrolle der Entwickler wichtig.
Wenn Entwickler ihre eigene Software als snap oder flatpak ausliefern, dann gibt es keinerlei Kontrolle mehr. Ehrlich gesagt, bei Ubuntu wäre es mir heute schon recht mulmig zumute firefox zu benutzen.
> Die Struktur mit Maintainern hat sich über die Jahrzehnte als sehr sicher herausgestellt. Die Maintainer sind zur Kontrolle der Entwickler wichtig.
Da gebe ich dir recht, allerdings ist das nicht die Aussage vom Vorposter. Der Vorposter sagt, dass da leichter Malware reinkommt. Das kann auch durch einen Maintainer passieren.
> Wenn Entwickler ihre eigene Software als snap oder flatpak ausliefern, dann gibt es keinerlei Kontrolle mehr. Ehrlich gesagt, bei Ubuntu wäre es mir heute schon recht mulmig zumute firefox zu benutzen.
Das Beispiel ist insofern schlecht, da gerade bei Firefox in aller Regel auch Committer bei RedHat, Canonical und Co. hocken.
Wenn du eine Entwicklerriege von mehr als 10 hast, wer ist da der Entwickler?
Wovon träumst du so? Maintainer führen doch keine Codeaudits durch, schon garnicht bei so großen Projekten wie ein Browser. Das wird gebaut, getestet und bereitsgestellt. Schluss. Alles auf Vertrauensbasis.
naja, so ist das auch nicht. es gibt durchaus maintainer, die auch in grösseren projekten sich changes anschauen. Ich mein, genau DAS hat ja das openssh debakel ausgelöst, dass sie nicht verstanden haben, dass der zufall von uninitialisierten variablen kam und sie das gefunden und geprüft haben mit valgrind und das entfernt hatten.
ausserdme können maintainer in projekten ja durchaus auch in dem projekt entwickler sein, aber halt nicht “upstream entwickler”
Siehe z. B. https://cstan.io/?p=13062 unter Geschwindigkeit. Eigene Messungen haben das bestätigt.
So wie ich das Distributionsmodell verstehe, kann jeder mit einem Github Account zu Flathub beitragen. Bei Distributionen reicht es i.d.R. nicht einfach irgendwo einen Account zu eröffnen um Pakete in eine Distro einfließen zu lassen. Für potenzielle Angreifer ist es somit relativ leicht, böswillige Software einzuschleusen. Dies ist bei Distributionen deutlich schwerer.
> Siehe z. B. https://cstan.io/?p=13062 unter Geschwindigkeit. Eigene Messungen haben das bestätigt.
Komisch, das ist mir beim Verwenden von Firefox noch nie aufgefallen. Muss ich mal anschauen. Aber da würde mich auch mal ganz ehrlich ein Vergleich von Firefox in SELinux oder Apparmor dann interessieren, weil ich behaupte, das KOMMT durch die Sicherheitsmechanismen da drin unter anderem.
> So wie ich das Distributionsmodell verstehe, kann jeder mit einem Github Account zu Flathub beitragen. Bei Distributionen reicht es i.d.R. nicht einfach irgendwo einen Account zu eröffnen um Pakete in eine Distro einfließen zu lassen. Für potenzielle Angreifer ist es somit relativ leicht, böswillige Software einzuschleusen. Dies ist bei Distributionen deutlich schwerer.
Nunja, Fedora hat schon ein eigenes FlatpakRepo, SUSE plant/hat auch eins. Bei Appimage machts gleich nur der Upstream.
Aber ein Maintainer kann doch auch ein Angreifer sein? Und Flatpak Buildinstruktionen sind einfach zu lesen und ziehen beim Bauen von der Quelle. Wo ist das jetzt riskanter, als direkt von der Quelle zu bauen?
BrowserBench.org coole Seite, aber diese Messungen sind nicht wirklich repräsentativ, da sie in einer VM durchgeführt wurden?? Absolut Fail.
So ist es, deswegen ist es schlauer Flatpak-Apps zu nutzen und ggf. vorher mit Flatseal zu überprüfen welche Rechte vergeben worden sind. Auf dem Papier ist Flatpak schon ziemlich sicher und gut durchdacht.
Das ist aber deutlich schwerer, zumindest bei den großen Distros. Wenn ich ein Angreifer bin und überleg, wie ich am besten Malware unter Linux unter die Leute bringe, fallen mir u.a. diese Wege ein:
Wenn ich Schadsoftware direkt in Debian (als Beispiel) einschleusen wollte, müsste ich zunächst mal Maintainer werden, und das ist nicht ganz einfach, siehe https://wiki.debian.org/DebianMaintainer. Ich sage nicht, dass das unmöglich ist, aber doch deutlich erschwert ggü. einem einstellen bei flathub.
Natürlich sind die Bedenken dort ähnlich überall dort, wo man fast ohne Kontrolle irgendwas bereit stellen kann. Z.B. fällt mir das Arch User Repositrory ein (AUR), wo es ebenfall im Prinzip reicht, sich einen Account zu erstellen.
Du gehst von der falschen Prämisse aus, dass man nicht schon jahrelange wo als Maintainer arbeitest und aus $Gründen dann Malware einschleust. Immerhin gibts auch bei Firmen insiderthreats. Ja, mehr Augen helfen und ich glaube auch in der Mehrzahl wird es mit mehr Entwicklern und Maintainern und Reviewern besser, aber in der Theorie verhindert das System nicht, den irgendwann der Rappel/die Wut packt, dass ein Maintainer keinen schadcode einschleusst.. vielleicht sogar aus “wartungsgründen”…
Das Risiko gibt es aber immer, bei jeder Organisation (also z.B. auch bei Herstellern proprietäter Software) und insofern ist das außerhalb des Scopes des Szenarios “wie kann ein Angreifer Schadcode einschmuggeln und verbreiten”.
Das ist wahr, mir gings nur darum, dass die Ursprungsprämisse mal war, dass das Paket von jemandem kompromittiert werden kann. das kann bei flathub genauso wie bei debian passieren, weil bei flatpak ziehst du das in aller regel auch aus einer kuratierten quelle, wo du keine eigenen patches in aller regel nächladst. entweder vertraust du deinem flatpak repository maintainer und deinem debian maintainer, oder .. nicht.
aber zu sagen, flatpak wäre da unsicherer, da musst du mir erstmal zeigen, dass bei flatpak so viele patches dazu geladen werden, dass es wie bei debian gleich nen eigenen patches ordner manchmal braucht (apt-get source openssl && cd openssl-$version & ls debian/patches) oder dass flatpaks ohne review in das flatpak repo eingebunden werden…
Ich sag mal so: einem Debian Maintainer, der den Bewerbungs-Prozess duchlaufen hat ist eher zu vertrauen als einem Maintainer, der nicht näher überprüft wurde.
Dir ist aber schon klar, dass du 2 Bürgen brauchst und sonst nur technische Dinge da abgeprüft werden in dem Prozess? Ja, sicher, du musst mal mit Leuten online quatschen, aber Gesinnung oder psychische Stabilität wird da nicht abgeprüft.
Ich traue Debian z.B. ja auch (wesentlich mehr als Arch oder Gentoo!) auch weil es schon länger da ist, aber:
Wenn wir mal ganz ehrlich sind, ist die Gefährung bei Flatpak vs Debian nicht wesentlich unterscheidbar. Bei einem hast du einen mehr der draufschaut und Dinge reintun kann, dafür guckt die Community mehr drauf, weil auch es mehr patches sind. Beim anderen (Flatpak) gucken weniger Leute drauf (übrigens danke dafür, ich bin gerade mal am nachprüfen meiner flatpaks), dafür weniger patches drin
Die Entwicklung geht wahrscheinlich eher in die Richtung, dass der Distributor sich in Zukunft hauptsächlich um ein eher kleineres Basissystem kümmert. Die gewöhnlichen GUI-Anwendungen wie Browser, Bildbearbeitung, Büroprogramme … werden durch ein universelles Paketformat, beispielsweise Flatpak, direkt vom Entwickler bezogen. Meiner Meinung nach eine überfällige Entwicklung, die den Distributoren viel Arbeit abnimmt.
Ich halte es nach wie vor skeptisch gegenüber Snap oder anderen zu sein, bei Ubuntu kommt man ja nicht mehr daran vorbei, deshalb bin ich kürzlich erst wieder zu Debian gewechselt, ich muss allerdings auch nicht den allerneusten Kram haben. Von Ubuntu ist man ja gewohnt, das die gerne ihr eigenen Kram basteln, wie zum Beispiel Unity.
Ich finde das wichtig, dass die Entwicklung grundsätzlich weiter voran getrieben wird.
Auch hier wäre das wieder wünschenswert, wenn alle vereint an einem Strang ziehen würden und ein standardisiertes Format entwickelt würde … aber das ist ein Träumchen und anderes Thema.
Ich nutze Debian Bullseye grundsätzlich mit den Paketen aus dem offiziellem Repo und eine zusätzliche Quelle für den Vivaldi.
Meine Erfahrung für Debian: Um so weniger Fremdquellen- und Pakete, um so stabiler läuft das System. Allerdings muss ich auch sagen, dass es wünschenswert wäre, hier und da neuere Versionen haben zu können (alleine aus dem Sicherheitsaspekt). Davon abgesehen, muss eine Möglichkeit gefunden werden, proprietäre Software sicher einbinden zu können (z.B. Spotify, …).
Wenn Linux nur den Hauch einer Chance auf dem Desktop und vielleicht in Firmen, Behörden, … haben möchte, dann braucht es hier eine Möglichkeit.
Davon abgesehen muss ein System sicher und zuverlässig mit wenig Aufwand zu administrieren sein.
Ich selber habe Appimages schon ausprobiert und finde diese Möglichkeit für Ausnahmen ganz gut. Ähnlich wird das mit Flatpaks sein, kann ich aber nix zu sagen, da noch nicht ausprobiert.
Ich finde das der Vorteil von einem einheitlichen und übergreifenden Paket Format auch Reduzierung von Ressourcen bedeutet. Das wird in dem Artikel so m.M.n. nicht genannt.
Distributionsübergreifend bedeutet Synergien die wichtig sein könnten.
In diesem Bereich scheint Bewegung eingekehrt zu sein und das finde ich erst einmal gut.
Irrwege wird es immer wieder geben aber am Ende kommt hoffentlich das Beste dabei heraus.
Ich nutze Flatpaks nur wegen der Plattformunabhängigkeit oder Debians alten, verkrusteten Paketen.
Egal welches OS, die Anwendung ist die selbe. Bei Debian ist KeePassXC ein gutes Beispiel. 2.6.2 ist in den Repos, aktuell ist 2.6.6. Debian macht Ausnahmen für Firefox und Thunderbird. Aber sicherheitsrelevante Software bekommt keine, na wunderbar.
Manchmal wünsche ich mir ein Unternehmen hinter Debian, so wie es bei RedHat der Fall ist. Da gibt einer die Marschrichtung vor und alte Zöpfe werden abgeschnitten und nicht jahrelang ein alternatives Init-System mitgeschleift. Sowas bindet Ressourcen die man z.B. in die Paketierung setzen könnte um einige wichtige SW wie KeePassXC ebenfalls aktuell auszuliefern. Aber jetzt wird es zu politisch…
? Dann wäre es ja aber nicht mehr Debian. Aus meiner Sicht ist das eines der Alleinstellungsmerkmale von Debian, ein Gemeinschaftsprojekt zu sein.
Warum nutzt du denn nicht Redhat oder Suse?
Und nebenbei, die Redhat-Pakete sind nun wirklich auch kein Ausbund an Aktualität.
Fair point, manchmal braucht man einfach jemand der durchgreift, das ist in dem System Debian nicht möglich.
Ich nutze RedHat selbst, die Basis ist solide. RedHat hat allerdings etwas gegen die alten Pakete getan: AppStreams. Somit ist auch das Argument RedHat wäre alt hinfällig.
Bei Debian fallen mir da immer die Backports Geschichten ein. Ja, nicht so Klasse und Konsistenz… ah, leidiges Thema, aber es gäbe eine Möglichkeit. Fürs Server vermutlich noch weniger eine gute Idee wie für Desktops … Ich hatte das mal auf einem Desktop System am laufen und das hat gut funktioniert. Aber ich glaube nicht (Debian warnt auch davor) das es ein System wirklich besser im Sinne von stabil und sicher macht.
Ich ziehe Flatpaks selbst den “normalen” Paketen vor. Allerdings schaue ich auch immer nach, wer das Flatpak pflegt bzw. ob die Version denn aktuell ist.
Dass der Job des Maintainers wegfällt, stört mich nicht. Wenn ich überlege, wie viel duplizierte (weil für jede Distro extra) Arbeit da eigentlich geleistet wird, wird mir schlecht.
Ich glaube, Flatpak wird das Rennen auf dem Desktop machen.
Ich nutze auf meinem Debian 11.4 auch Flatpak. Aber auch nur für wenige Programme, alles andere kommt aus dem Repository. Es ist eine neue Methode Programme zu nutzen, unabhängig vom verwendeten DE. Bsp. Gnome als Desktop und per flatpak KDevelop.
Es hat auch einen sicherheitsrelevanten Aspekt, das alles in /home/ bleibt und sich jeder Anwender auf dem System sich seine Programme von flathub etc. zieht.
Es mag evtl. auch nicht für jedes Szenario/Umgebung passen.
Also ich feier Flatpaks auch voll ab. Sowas hat Linux gebraucht. Das der Maintainer dadurch wegfällt ist super. Stand eh nur im Weg und hat ein zeitnahes veröffentlichen nur erschwert oder gar verhindert. Weg damit.
Ich sehe für mich jetzt keinen Grund für Alternativsysteme. Ich virtualisiere viel, dort sind Programmsets für definierte Einsatzzwecke drin.
Aber es ist schon nachvollziehbar so etwas zu benutzen, wenn das System z.B. ein veraltetes Debilian ist.
Ich bin gerade dabei mein Steam Deck als meinen neuen PC einzurichten. Mein ursprünglicher Plan war es, das SteamOS so zu verwenden, wie es Valve vorgesehen hat. Und das würde bedeuten, dass ich Software nur als Flatpak installieren kann, da das read-only Dateisystem von SteamOS es nicht möglich macht, pacman zu verwenden.
Diesen Plan musste ich allerdings aufgeben, da ich das deutsche Sprachpaket für KDE nicht installieren kann. Viele Systempakete sind halt prinzipbedingt nicht als Flatpak verfügbar.
Für Anwendungen ist Flatpak sicher sehr gut geeignet, wobei mir manchmal aufgefallen ist, dass sich Flatpak Anwendungen nicht an die Konfiguration des Desktops halten. So hatte ich z.B. die DPI in den Desktop-Einstellungen auf 125% gestellt, aber die Flatpak-Anwendung hat das ignoriert.
Aber die eingeschlagene Entwicklung von distributionsunabhängigen Anwendungspaketen halte ich für richtig.
Flatpaks enthalten in der Regel alle Sprachpakete, ohne das man etwas dazu tun muss. Das SteamOS bei der Lokalisierung geschlampt hat, ist ein Fehler von Valve, nicht von den Paketsystemn.