Beiträge von Scytale

    Das technisch "einfachste" wäre die Nutzung der Flatpak-Version, aber die ist ebenfalls wie deine genutzte Version von einer dritten Partei. Gut, im Grunde passiert da keine schwarze Magie, sondern lediglich wird das .deb Packet einfach umpacketiert, aber es kommt halt nicht mehr direkt von signal.org. Aber wenigstens läuft das flatpak technisch stabiler, weil bei TW sich die basis so schnell ändert und Dritt-Repos kurzzeitig kaputt gehen können.

    Flatpak ist in einem anderen Sicherheitskontext. Bei Flatpak werden keine Repo-Pakete überschrieben, und für eine Kompromittierung von Systemdaten bräuchte man eine Exploit-Chain, was objektiv schwerer ist, als ein bösartiges Paket in Packman auszutauschen. Es geht hierbei wieder um Wahrscheinlichkeiten, und was das kleinere Übel ist. Und Flatpak Apps sind aus Sicht der Sicherheit und Systemstabilität das kleinere Übel. Distros wie Debian empfehlen explizit Flatpak vor Dritt-Repos, wenn eine App nicht im Hauptrepo sei.


    Die xz Lücke ist imho eine ganz andere Kategorie als Supply Chain attack. Bei Packman ist die größte Gefahr keine Supply Chain Attack, sondern dass ein inkompetenter/Bösartiger Akteur direkt Pakete manipuliert. Das heißt, dem entsprechen ist hier von der Wahrscheinlichkeit Packman gefährlicher, weil von xz-Lücke betroffen, aber gleichzeitig auch noch zusätzlich von den o.g. Gefahren als Dritt-Repo. Und die xz Lücke bei Flatpak wäre dann immer noch in einem Sandbox Kontext und im Worst Case erstmal nur Teile der Userdaten betroffen und ohne Exploit Chain und Manipulation von SE Linux bliebe alles im User-Kontext und nicht als root.


    Und um Alero aufzugreifen:

    Ja, es gibt keine Sicherheit. IT Security bedeutet nur sicherzustellen, dass dein System etwas schwerer zu übernehmen ist, als das eines anderen. Der Angreifer wählt i.d.R. den leichtesten Weg.


    In dem Sinne: Wenn ein Angreifer die openSUSE Leap/Tumbleweed User in der Breite kompromittieren wollen würde, wäre der leichteste Weg, das Packman Repo anzugreifen. Das ist bei den meisten unbedarften Usern Standard.

    Ich beziehe mich wieder auf meinen #2 Post:



    Richard Brown 1


    Richard Brown 3:


    Wir sind gerade auf einer unterschiedlichen Ebene. Du guckst dir den Code an, ich überlege mir, was passiert, wenn jemand bei Packman Mist baut.

    Noch einmal:

    Packman benutzt die factory Pakete von openSUSE, also die Pakete, die demnächst in Tumbleweed erscheinen. Du kannst ein diff über die Sourcen laufen lassen, die Sourcen sind gleich. Die Sourcen aus factory werden nur als Branch weitergereicht.


    Das Problem für Packman Tumbleweed ist halt das factory Repo, dort können schon andere Sourcen verbaut sein, als Tumbleweed noch vorhält.

    Ich verstehe deine Ergänzung nicht. Die Sources kommen aus Factory, werden mit Propräritären Code erweitert, um die Codecs zu unterstützen. Damit ist es technisch ein Fremdpaket und wird dann nicht mehr im openQA im ganzen mit allen anderen Paketen getestet. D.h. da ist eine gewisse Menge an Code-Änderung, die explizit nicht von openSUSE kontrolliert wird; und das hat Implikationen hinsichtlich Sicherheit und Stabilität. Genau an der Stelle könnte ein Bad Actor eingreifen.

    Ich sag nur, es gibt einen Grund, warum der Support für jegliches Softwareprodukt als erstes fragt:


    • Ist ihr OS auf der aktuell verfügbaren Version und haben sie alle verfügbaren Patches von unserer Software eingespielt? Nein, dann bitte machen Sie es, bevor wir ihnen weiter helfen können.


    Als quick&dirty Workaround sollte auch die Flatpak Version von Evolution helfen können. Das könnte auch einfach ein Bug sein, der in den neueren Versionen von Evolution gefixt ist, aber nicht in der von Leap 15.6.

    Leap und Packman laufen bei mir ideal. Seit Jahrzehnten! Flatpak vermisse ich daher nicht.

    Das ist auch erwartbar, dass Leap&Packman sehr viel besser harmonieren als TW mit Packman, was die Stabilität angeht. Hinter Packman steht kein openQA wie bei TW. Das heißt im Klartext, die Qualtität ist vergleichbarer mit einem Debian Sid oder einem Testing Zweig von Arch. Und das fällt dann bei statischen Releases wie Leap halt logischerweise weniger ins Gewicht als bei einem Rolling Release.


    Was ich mit den Richard Brown Zitaten auch noch erwähnt habe in den ersten Posts: Du öffnest dir dein System potentiell für Angreifer. Eben weil Kern-System-Pakete von Leap/Tumbleweed von Packman-Versionen gehijackt und ersetzt werden, die zudem nicht den gleichen hohen Standard an QA durchlaufen, kann das super gefährlich sein. Das heißt, bei Packman ist die warscheinlichkeit einfach höher, dass jemand Mist baut und Dinge nicht funktionieren, oder -Omnissia bewahre-, Dev PCs werden von Malware verseucht und jemand bösartiges hat Zugriff auf Packman Infra.


    Das heißt, es geht einfach um das Spiel von Wahrscheinlichkeiten. Es ist wahrscheinlicher, dass dein System wg. Packman kaputt gepatched wird, als wenn du es nicht benutzen würdest. Es ist wahrscheinlicher, via Packman repo mit Malware infiziert zu werden als über das Hauptrepo. Es ist wahrscheinlicher, dass du unnötige Wartungsarbeiten im Terminal machen musst, wenn du Packman hast als wenn du es nicht hättest. Aber wie wahrscheinlich ist das? Keine Ahnung.


    Ich möchte mein System einfach so sicher und stabil haben, wie es mir möglich ist, ohne viel auf Komfort zu verzichten. Für mich ist das Fazit klar, weil overall Tumbleweed ein schlechteres OS ist mit Packman, und es mir sogar mehr Arbeit macht. Ich möchte so wenig wie möglich mit Maintenance beschäftigen, und das Optimum hab ich mit dem beschriebenen Verzicht von Packman und der ausgwählten Nutzung von Flatpaks erreicht.

    Gut für dich.

    Ich z.B. habe vor zwei Wochen wg. der GRUB-BLS Änderung mein Hauptsystem neu aufgesetzt, mit 'opi codecs' packman mit allen Codecs installiert, und direkt am nächsten Tag lief 'zypper dup' nicht durch, weil Abhängigkeiten wg. Packman nicht mehr aufgelößt werden konnten.

    Eine Woche später wurde dann der komplette Mesa Stack in TW aktualisiert. Upgrade lief ebenfalls nicht durch, weil die Dependencies den Wechsel zurück auf die TW Version verlangt haben. D.h. an der Stelle muss ich auf möglicherweise kritische Sicherheitsupdates verzichten, oder die Repo-Version wechseln.

    Und als dann einen Tag später der Mesa Stack auch in packman aktualisiert worden ist, hatte ich das Problem, dass das System beim Autosuspend zu 100% reproduzierbar gefreezed ist. Das ging sofort wieder nachdem ich auf alle Pakete aus dem Hauptrepo gewechselt bin, und Packman entfernt habe. So was ist mir in den letzten 5 Jahren schon das ein oder andere Mal passiert.


    Meine Schlussfolgerung ist genau die, wie in den ersten Posts beschrieben: Das QA von Packman ist einfach schlechter als vom Hauptrepo. Wenn man auf Stabilität und Sicherheit setzt, sollte man es nicht benutzen. Haltet mich für wahnsinnig, aber nur mit dem Hauptrepo ist das upgraden so zuverlässig, dass ich das sogar mit Discover beim reboot wegautomatisieren kann.

    Ich widerspreche dir, weil anekdotisch basierte Evidenz ist keine Evidenz.


    Edit:

    Das heißt, es ist gibt eine Schwelle, an der Hilfe geben unsinnig wird, wenn der User unsinnige, selbst gebaute Konstrukte betreibt, die keinen Sinn mehr ergeben. Im IT Job ist Schritt eins beim Support erstmal herauszufinden, ob der User auch wirklich das Problem hat, dass er schildert. Hier setzt sich für mich mit dem vorherigen Thread des TEs ein Bild zusammen. Ich empfehle einfach, sich "clean" für ein OS zu entscheiden, m.M.n für ein Linux OS, sogar nicht TW sondern ein Stable Linux wie Debian, wenn irgendwie berufliches darauf gemacht wird, und darunter dann alles zu virtualisieren.

    Sorry für Doppelpost, darf nicht mehr editieren.


    FAT32 wird offiziell nicht supported von Virtualbox. Die empfehlen ganz klar NTFS und ext4. D.h. selbst wenn es läuft, dann nur mit schwer degradiertet Performanz und erhöhter Ausfallwahrscheinlichkeit. Bei der VMWare Konkurrenz ist das ebenso.