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.
Beiträge von Scytale
-
-
Alles anzeigen
Und du meinst also bei flatpack könnte nichts passieren?
Hast du dir mal durchgelesen, was mit dem xz-Problem dieses Jahr eigentlich erreicht werden sollte?
Und wie dies überhaupt geschah?
Gibt es 4 schöne Artikel in einem C't Sonderheft.....
Mit so etwas ist es egal ob flatpack oder Repo oder was auch immer.
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:
ZitatAlles anzeigenReputation is really simple - if it’s in the official repos, it’s trustworthy.
If it’s not, then it’s not trustworthy.
For a more nuanced view - If it’s in a “devel” project, it MIGHT be somewhat (but less) trustworthy, IF it’s a devel Project with a good team ethos and practices of reviewing and collaboration that rival the regular Factory process. https://en.opensuse.org/openSUSE:Factory_development_model
This is generally not the case for most devel projects, hence that process existing.
Home projects are even more untrustworthy - unless you really exceptionally trust the person maintaining it. I don’t - I don’t even trust my own home: project - I’m always breaking the stuff I use from there
Hope this helps
Rich
TW Release Engineer/MicroOS Release Manager
ZitatAlles anzeigenPackman is not vetted, nor safe.
The packman team have repeatedly ignored requests from folk like me to address very real world issues.
Packman repeatedly overrides tumbleweed packages, which is very hostile behaviour and results in broken user systems on a regular basis.
Games, science, etc are what we call devel repos
They are not formally vetted, but they are where things should be built before they are sent to Tumbleweed, where they are vetted and tested.
So, they can’t be trusted like Tumbleweed can, but they might be insightful if you want to help test and build stuff for TW
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.
-
Leap 15.6 ist ja noch aktuell und wird bis Ende April 26 unterstützt.
Evolution ist aber gebundelt mit der Gnome-Version, die Leap 15.6 ausliefert. Das ist wie bei Debian/Ubuntu/etc: Security Fixes von den Upstream Versionen werden backported, aber normale bugs werden i.d.R. nicht gefixt.
-
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.
-
Alles anzeigen
Moin,
also... Ich finde, du übertreibst. Hier betreibe ich auf unterschiedlichen Laptops schon lange Multibootsysteme (Linuxe und Windowse). In (fast) allen O/S ist Virtualbox installiert. Ettliche *.vdis werden sowohl in den Linux- wie auch in den Windows O/S aufgerufen, selbstverständlich immer ein und dieselbe *.vdi (genau das, was Dirk68 machen will).
Mehr sogar noch, die div. O/S können z.T. auch jeweils als RAWdisk gestartet werden.
Und ja, hin und wieder sind dabei schon chkdsk bzw ntfsfix mal notwendig, hat bisher immer funktioniert.
LG b_b
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.