News Ubuntu 21.10 („Impish Indri“): Firefox wird wie Google Chrome als Snap ausgeliefert

[Helge01]

Flatpak
Vorteil, hohe Sicherheit durch Permissions statt nur "Dateirechten" und Entwickler haben mehr Kontrolle über die Auslieferung.

https://flatkill.org/
https://flatkill.org/2020/
Flatpak ist eine Katastrophe in Sachen Sicherheit.

Snap Code ist proprietär und hat in einer Linux-Distributionen nichts zu suchen.
Dadurch habe Canonical die Möglichkeit, Hintertüren in Ubuntu einzurichten.
Quelle

Das ganze ist keine gute Entwicklung.

 

[andy_m4]

Verstehe auch nicht, warum Ubuntu immer wieder genau das angekreidet wird, was sonst ein definierendes Merkmal des Linux Ökosystems ist.

Ich glaube das liegt daran, das ubuntu erfolgreich ist. Und dann gibts halt auch viele Neider die dann nix Besseres zu tun haben als da ganz genau "hinzugucken". Und dann gibts vor allem viele Nachplapperer die einfach nur Vorwürfe unreflektiert wiederholen, weil es wohl "cool" ist gegen ubuntu zu sein. :-)

 

[Linuxfreakgraz]

@andy_m4
Nicht alle Entscheidungen von Canonical sind das gelbe vom Ei.

Die anderen Distributoren machen aber auch nicht immer die besten Entscheidungen, zum Beispiel SystemD zur Bloadware aufzublassen. Stichwort RedHat.

 

[Pessimist 80]

Wenn man ein Laie ist und keine Nvidiakarte hat, Fedora.

Nvidia ist kein Problem wenn man nicht zocken möchte. Läuft wunderbar auf meinem HP Omen mit zwei Bildschirmen und Nvidia RTX 2070, mit Nouveau Treiber und Wayland. Bin kein Laie finde aber Fedora bis heute eine der besten Distros wenn man Gnome mag.

Secureboot und TPM 2.0 aktiviert im Dualboot, funktioniert alles einwandfrei.

 

[garfield121]

@SV3N
Es wird nicht Google Chrome ausgeliefert als Snap, sondern Chromium.

 

[Hörbört]

Boah, diese Snap-Pest.

Da man unter Ubuntu immer schwerer um Snap herum kommt, ist es für mich leider tot.
Wird Zeit, dass ich mal meinen Arsch hoch bekomme und auch auf dem letzten Rechner das Kubuntu runter werf.... hart keinen Bock mehr drauf!

 

[Garmor]

Die Frage ist wahrscheinlich eher, was die ganzen Derivate machen, wenn langsam alles auf Snap umgestellt wird. Suchen die sich dann andere Vorlagen oder sehen die am Ende sogar eine Erleichterung darin?

 

[nipponpasi]

Ich kann verstehen wenn Manchen snaps, flatpaks oder appimage nicht zusagen.
Für mich allein würde pacman oder apt auch vollkommen ausreichen.
Als Hobby-/Familienadmin jedoch hab ich in den letzten Jahren besonders snaps zu schätzen gelernt. Da sie für mich einfach eine erhebliche Zeitersparnis, durch viel weniger Wartungsaufwand auf den restlichen Rechnern im Familiennetzwerk, bedeuten.
Obwohl meine Tochter aktuell Windows nutzt. Aber das ist wieder ein anderes Thema.

 

[Gorgone]

Ich unterstütze vollständig die snap Pakete da diese kuratiert werden und zentral abrufbar wie bei jedem vernünftigen Store sind. Die Leute, die immer meckern, dass snap proprietär ist sollten sich mal die Geschichte anschauen, warum diese Entscheidung so getroffen wurde, ich kann das vollständig nachvollziehen, warum kann Canonical so gehandelt hat. Und schließlich ist keiner gezwungen snap Pakete zu verwenden, da diese rein optional sind, jeder kann immer noch tars verwenden.

 

[andy_m4]

Die Leute, die immer meckern, dass snap proprietär ist sollten sich mal die Geschichte anschauen, warum diese Entscheidung so getroffen wurde, ich kann das vollständig nachvollziehen, warum kann Canonical so gehandelt hat.

Hilf' mir mal bitte auf die Sprünge. Was war der entscheidende Grund Snap(teile) proprietär zu machen?

 

[tukse]

Für alle die noch mehr Gründe brauchen, Ubuntu NICHT zu verwenden.

 

[garfield121]

Die Geschichte zeigt vor allem, das Projekte von Canonical grandios gescheitert sind.
Rein optional stimmt leider nicht, denn es geht darum, wichtige Programme nur noch als Snap auszuliefern, nicht mehr als Deb!

 

[Linuxfreakgraz]

appimage

Damit hatte ich noch nicht solche Schwierigkeiten wie bei Snap, weil appimage noch nicht Sandboxed ist.
AppImage macht deutlich mehr Sinn da dort Entwickler auf keine Plattform angewiesen sind und das Image gleich über Ihre Homepage verteilen können.

Bei klassischen Repositories, Flatpak oder Snap ist man auf Dritte angewiesen.
Oder man muss bei Flatpak oder Repositories selber eine solche Infrastruktur warten. Hat zB bei Repositories auch noch zusätzlich das Problem mit Abhängikeiten wie bei PPAs.

AppImage scheint mir das Sinnvollste zu sein aber nicht immer wird das Sinnvollste zum Goldstandard.

Selbst Linus verwendet ausschließlich AppImage zur Verbreitung seiner Taucher App. Ja Linus Benedict Torvalds ist leidenschaftlicher Taucher und hat neben seiner Kernel Maintainer Tätigkeit eine TaucherApp am Start. Und der schwört auf AppImage.

Das hat auch den Vorteil das man AppImages auf einer anderen Festplatte archivieren kann. Unabhängig von der Distribution.

 

[GrumpyCat]

Doppelt gemoppelt ist in dem Fall nicht zwingend ein Sicherheitsgewinn

Sandboxing kann man auch einfach per systemd machen, das kann einen Haufen Zeugs in der Richtung (cgroups, capabilities etc.).

Davon abgesehen ist Sandboxing so (also auf Prozess-Ebene) bestenfalls bei wenigen Server-Prozessen sinnvoll, sonst nur von der Anwendung selbst gemanagt. Kann man einfach beim Browser sehen: Wie soll man den sinnvoll allgemein sandboxen, wenn er doch ab und zu auf Mikro und Kamera zugreifen oder auch Dinge von frei wählbaren Stellen des Dateisystems laden und speichern können muss?

 

[Piktogramm]

Zum 10jährigem werde ich also motiviert mit Distributionshopping anzufangen :/

@GrumpyCat
Egal wie, Schnittstellen brauchen Programme in Sandboxes sowieso. Selbst bei Servern wie du es schreibst muss ja mindestens Netzwerkverkehr ein und ausgeleitet werden. Vollständig isoliert läuft in der Regel nie etwas.

 

[ShiftyBro]

... Will man sowas, kann man auch gleich zu Windows gehen...

Hm, ich sehe das von meiner Warte anders herum: Um von Windows wegzugehen, habe ich mir immer sowas gewünscht.^^
Jedes Mal, wenn ich wieder Linux ausprobiert habe, bin ich irgendwann bei irgendeinem Programm an den Punkt gekommen, wo es hieß "dieses Programm gibts jetzt für deine aktuelle Distribution nicht, aber kannste ja selber kompilieren, wenn du Zeug dazu hast". Oder "für das Programm hast du die nötigen Abhängigkeiten irgendwie nicht drauf". Das war dann so ca. der Moment, an dem ich die jeweilige Distribution wieder deinstalliert habe und wieder weiter Windows genutzt habe.

... und still und heimlich gehofft habe, dass sich mal ein einheitliches System durchsetzt, mit dem man direkt vom Hersteller des Programms kommende Software auf jeder Linux-Distribution installieren kann, egal ob der Herausgeber der jeweiligen Distribution bzw. Betreuer der Repository diese Software für relevant hält oder nicht.

 

[andy_m4]

Davon abgesehen ist Sandboxing so (also auf Prozess-Ebene) bestenfalls bei wenigen Server-Prozessen sinnvoll,

Also "sandboxing" ist natürlich auch auf dem Desktop sinnvoll. Es gibt ja keinen plausiblen Grund, warum mein Musikplayer außer auf meine MP3-Dateien oder Webradio auch auf meine Office-Dateien zugreifen kann, so das im Fall eines Exploits dann meine Diplomarbeit geransomwared wird.
Auch ein Browser braucht ja üblicherweise außer dem Cache-Verzeichnis und im Download-Verzeichnis keine Schreibrechte.

Das sind alles Dinge die durchaus Sinn machen. Die Frage ist hier nicht, ob das Sinn macht, sondern wie ich es in eine Form gieße, das es auch für den gemeinen Anwender praktikabel ist. Einfach nur Rechte vorzugeben wird schwierig. Denn jeder hat ne andere Vorstellung davon, was beschränkt werden soll.
Beim einen soll LibreOffice nur auf odt-Dateien zugreifen können. Ein anderer will vielleicht auch mal Bilder im Text einbauen. Da soll LibreOffice also auch Bilder lesen können dürfen sollen.

Die Alternative ist, man gibt die Rechte nicht vor sondern beschränkt pauschal und fragt dann den Anwender beim Zugriff, ob der erlaubt werden soll. Solche Meldungen werden aber oft als nervig empfunden (das kann man abmildern; indem man die Möglichkeit gibt sich die Auswahl zu merken usw.) und viele aber auch einfach schlicht überfordert.
Das sehe ich auch also als Grundproblem bei Lösungen wie Snap. Die sollen ja explizit auch einfach sein und den User nicht großartig nerven. Das heißt aber, Du hast dann eher sehr allgemeingehaltene und damit nicht sehr strenge Security-Policies die mehr erlauben als eigentlich nötig.

Das ist halt die große Schwierigkeit. Wie verbinde ich diesen durchaus sinnvollen Ansatz mit den Bedürfnissen und Fähigkeiten des vielzitierten Otto-Normal-Anwenders.

Das ist übrigens auch der Grund, warum man bei Servern da viel weiter ist. Nicht weil es da sinnvoller ist (also klar; generell hat da Security natürlich einen anderen stellenwert), sondern weil die üblicherweise auch von Leuten aufgesetzt werden, die sich entsprechend auskennen.

 

[Serana]

Ich frage mich gerade vor allem eines:
Wenn es auf meinem System ein Sicherheitsproblem durch veraltetet Bibliotheken in einem oder mehreren Snap-Paketen gibt, wen darf ich dann verantwortlich machen? Ich selbst kann ja nicht kontrollieren welche Bibliotheken in welcher Version in so einem Snap-Paket stecken. Canonical wird auf den Entwickler verweisen der gleichzeitig der Maintainer des Pakets ist. Der Entwickler/Maintainer wird auf Canonical verweisen weil es dort ja immer heißt, daß alles total sicher ist.

Am Ende kann ich mir dann nur an die eigene Nase fassen, da ich Software genutzt habe die eine sicherheitstechnische Wundertüte ist. Nur, bin ich dann als Otto Normaldau nicht eigentlich bei Windows besser aufgehoben?

Der große Vorteil bei Open Source Software sei, daß der Nutzer die Kontrolle über sein System behalte, aber wie viel Kontrolle habe ich denn bei den Containerformaten wie Snap, Flatpak und was es da sonst noch gibt denn überhaupt noch?

Am Ende haben wir dann auf der einen Seite Distributionen die quasi nur noch ein Framework für Snap oder Flatpak liefern und ansonsten nicht viel eigenes aufzuweisen haben, und auf der anderen Seite gibt es dann die Distributionen die noch ganz Old School Pakete bereitstellen.

Klar ersparen Formate wie Snap oder Flatpak den Distributionen Arbeit. Denn wenn es irgendein Problem in Zusammenhang mit einem Paket gibt kann man einfach auf den Entwickler verweisen. Der hat das Paket ja schließlich geschnürt. Auf der anderen Seite glaube ich kaum, daß die Entwickler bereit sind diese Verantwortung dann tatsächlich zu tragen. Stattdessen dürften diese dann häufig auf den alten Grundsatz verweisen, nach dem der Nutzer für das was er sich auf sein System packt vollständig selbst verantwortlich ist.

Es geht mir dabei nicht um mich selbst. Zum einen kann man so ein Paket auch immer entpacken und unter die Lupe nehmen, zum anderen habe ich bei OSS auch immer die Option mir den Quellcode zu holen, ihn zu kompilieren und mir ein eigenes Paket zu schnüren das bequem aktualisiert werden kann wenn es ein Update gibt. Aber was macht jemand der das ganze Wissen nicht mitbringt? Darauf vertrauen das schon alles gut gehen wird? Da kann er auch bei Windows bleiben. Da hat er zumindest gelernt mit der Problematik umzugehen.

 

[nipponpasi]

@Linuxfreakgraz
Freut mich dass du und Linus so zufrieden mit Appimage seid. So soll es auch sein!
Für mich persönlich ist appimage das umständlichste der aktuellen Formate. Aber das ist nur meine Erfahrung und ich werde mich hüten Linus himself zu widersprechen. 😉

 

[Bigfoot29]

Soso... Ubuntu schießt sich also endgültig ins Abseits... war es bislang so, dass man den ganzen Snap-Kram deinstallieren konnte und trotzdem auf nichts wichtiges verzichten musste, wird es langsam Ernst.

Auf dem RPi kommt bei mir bislang deswegen schon kein Ubuntu mehr aufs System. Mein aktuellster Pi4 läuft mit Manjaro und "upstream"-Kernel sauber. Unter x86 war ich schon auch eine Weile auf Abstand (je nach Kisten/Aufgabe "Back to Debian" oder Arch). Ergo sind Empfehlungen für Ubuntu jetzt auch Geschichte.

Denn:

• Jeder halbwegs kompetente Security-IT-ler wird Dir bestägigen, dass Snap/Flatpak DISTRIBUTIONS-Werkzeuge sind und keine Sicherheitswerkzeuge.
• In den Software-Packungen - insbesondere bei SNAPs - jetzt endlich wieder ungepatchte Abhängigkeiten rumgammeln können. "Die Programmierer kennen ihre Apps besser?" Mag sein. Von Distribution haben sie aber keine Ahnung. Deswegen sollten Programmierer NIEMALS Distributor sein. Die haben keine Ahnung, ob/wann ein Sicherheitsfix für Abhängigkeit X oder Y kommt. Viel Spaß dabei, 30 Anwendungen (nicht) zu aktualisieren, weil eine SSL-Komponente wegen eines Bugfixes aktualisiert werden musste.
• In klassischen Distris ist es so, dass das gesamte (Haupt-)System unter Verwaltung des Distributors steht. Alle Anwendungen arbeiten nach "shared libraries"-Prinzip. Es gibt z.B. exakt eine libc-Bibliothek in der ganzen Installation, auf die Hunderte oder Tausende Programme zugreifen. Ist sie von einem Sicherheitsproblem betroffen, wird eine Datei aktualisiert und ab diesem Zeitpunkt sind Tausende Programme wieder sicher(er). Was ist jetzt also besser? Snap/Flatpak, wo jeder 0815-Dev sein eigenes Süppchen kochen kann oder ein zentrales System, dem man vertraut?
• Womit wir beim nächsten Punkt sind: Ubuntu gibt mit Snap die Kontrolle über die Anwendungen auf. Bislang kann ich mich z.B. bei Debian drauf verlassen, dass der Firefox dort so sicher ist, wie er es - Menschen machen Fehler und auch der Maintainer ist nur ein Mensch - sein kann. Sobald ich aber externe Repos einbinde, gebe ich die Kontrolle, das VERTRAUEN, das die User in das System haben, auf. Das musste zuletzt das Raspbian-Team feststellen, als sie ohne ein Wort Microsoft-Repos einbanden und sich dann noch wunderten, warum das ein Problem sei.

Ich kann durchaus den Vorteil sehen, mittels eines Containers alle nötigen Umgebungsdaten mitzugeben, damit mein geschriebenes Programm unter so vielen Widrigkeiten wie möglich trotzdem optimal läuft. Nichts anderes macht man letztlich beim "Containern" - Achtung, bitte im IT-Kontext nutzen, sonst wirds (un-)appetitlich - ja auch. Aber auch dann sähe ich eher Flatpak als möglichen Kandidaten.

Regards, Bigfoot29

PS:
[RANT] Sorry, aber immer wenn ich sehe, wie jemand, der angeblich was mit IT und Sicherheit zu tun hat, meint "wir packen das in Container und dann ist das sicher" und anschließend ein Skript startet, dass von irgend einer dubiosen Seite Container runterlädt und auf dessen Basis dann Dinge tut, dann bohren sich Dinge unter meine Fingernägel. Ich möchte solchen Menschen einfach nur wehtun dürfen...
Gleiches gilt übrigens auch für die ganze "pip"-Fraktion - bei Python - und wie auch immer das bei den anderen Programmiersprachen heißt... Die Security-Skandale der letzten Jahre verhallen aber völlig ungehört. Es kostet ja Bequemlichkeit, Quellen zu SUCHEN und zu verifizieren. Ein "pip3 lieblings-modul-mit-potentiell-schrägem-code" ist halt viel einfacher.
GNARF! [/RANT]