Toolbox: Isolierte Entwicklungsumgebungen zur Abwehr von Fehlern und Malware im Code in der Entwicklung

Sie möchten einen persistenten Benutzercontainer ohne Ihr /home? Ich versuche nur, die Anforderung/den Anwendungsfall besser zu verstehen. - Sagen wir, im Vergleich zu einem Standard-Wegwerf-Fedora-Container?

Betrachten Sie ein Unix-Konto, das sowohl zu Hause als auch am Arbeitsplatz verwendet wird. Für einen Arbeitscontainer ziehe ich es vielleicht vor, nur mein Arbeitsverzeichnis in den Container einzuhängen.

Betrachten Sie eine nicht vertrauenswürdige GUI-App. Es benötigt möglicherweise nur Zugriff auf einen bestimmten Ordner, um Dateien zu laden/zu speichern. Es benötigt keinen Zugriff auf meinen .ssh-Ordner und andere nicht verwandte Dateien.

Aus Sicherheitsgründen gibt Chrome OS standardmäßig keine Ordner vom Host für Container frei. Wenn Sie dort Daten aus Ihrem Home-Verzeichnis oder von einem USB-Laufwerk an die Container bereitstellen möchten, geben Sie diese explizit frei.

Die Containerisierung als Sicherheitsfeature verliert erheblich an Wert, wenn Sie dem nicht vertrauenswürdigen Container standardmäßig alle Ihre Daten überlassen!

@juhp Ich sehe, Sie arbeiten gut mit Haskell-Paketen. Nehmen Sie an, dass eines der Haskell-Pakete, die Sie remote installieren, kompromittiert wurde. Benötigen Haskell-Pakete Zugriff auf Ihren .ssh-Ordner oder Ihr Bitcoin-Wallet? Warum alles standardmäßig in Ihrer Haskell-Entwicklungsumgebung freigeben?

Vor kurzem gab es ein NPM-Modul, das Bitcoin noch lokalisieren könnte, wenn es installiert wäre:
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

Das Modul war beliebt und mein Team hatte es tatsächlich in unserem Baum installiert. Wir haben die anderen Kriterien nicht erfüllt, um einen Bitcoin-Diebstahl auszulösen, aber dieses Risiko wäre vollständig gemindert worden, wenn unsere Entwicklungsumgebung standardmäßig keinen vollständigen Zugriff auf unsere Home-Verzeichnisse hätte. Kein Mitarbeiter hätte sich dafür entschieden, seine Bitcoin-Wallet in diese Entwicklungsumgebung zu teilen.

Das ist absolut gültig, wird aber schwierig.

In der Praxis denke ich, dass der beste Weg darin besteht, die Ausführung von Toolboxen als separate Benutzer zu vereinfachen (vorübergehend neue Uids erstellen, jede mit ihren eigenen /home ) - dafür ist ein privilegierter Systemdienst erforderlich.

Wenn Sie nun einige Dateien freigeben möchten

Ist es möglich, Dateien/Verzeichnisse von einem Verzeichnis bind-mount auszuschließen?

Um sicherzustellen, dass ich die Herausforderung verstehe, sehe ich, dass das Mounten des Home-Verzeichnisses in einer Codezeile erfolgt

    --volume "$HOME":"$HOME":rslave

Aber die Herausforderung hier besteht immer noch darin, GUI-Apps und einige andere Funktionen zum Laufen zu bringen, da diese Funktionen erwarten, dass der Benutzer innerhalb und außerhalb des Containers gleich ist?

Dies ist eigentlich ein ziemlich wichtiges Merkmal. Ich denke, es ist in Ordnung, standardmäßig home zu mounten, aber es sollte möglich sein, einen Container auf nicht vertrauenswürdige Weise zu verwenden. Das Einhängen in einen Container setzt voraus, dass Sie dem Container vertrauen, was bei einem Wegwerfcontainer oft nicht der Fall ist. Selbst in einfachen Fällen wie dem Testen eines NPM-Moduls möchte ich die Gewissheit haben, dass es meinen Home-Ordner nicht zerstört.

@markstos Vielleicht können Sie testen, was Sie ohne den Home-Mount tun können oder wenn Sie nur ein bestimmtes Verzeichnis (cwd) mounten?

@juhp Eigentlich war dies der Showstopper für mich - ich habe aufgehört, Silverblue zu bewerten, als ich auf diese fehlende Funktion stieß. Wenn dies behoben ist, kann ich Silverblue einen zweiten Blick werfen. Ich war auch enttäuscht, als ich feststellte, dass es nicht einfach war, herauszufinden, wie man einen Ubuntu-Container ausführt, das ist das Betriebssystem, das ich zuvor verwendet habe.

Wenn Fedora Benutzer anderer Linux-Distributionen willkommen heißen möchte, wäre es ein guter Anfang, ihre alte Distribution einfach in einem Container auszuführen.

@markstos danke - ich bin nur ein weiterer Toolbox-Benutzer. :-)
Ich stimme voll und ganz zu, dass eine Erweiterung der Toolbox zur Unterstützung weiterer Betriebssysteme in der Tat sehr nützlich wäre.
Beachten Sie, dass Toolbox auch ohne Silverblue funktioniert (dh auf anderen Fedora-Editionen).

@juhp Eigentlich war das der Hammer für mich - ich habe aufgehört, Silverblue zu bewerten, als ich auf dieses fehlende Feature gestoßen bin

Was hast du vorher gemacht? Gibt es ein anderes Tool/Ansatz, den Sie verwendet haben, der bei Silverblue nicht funktioniert hat?

Nichts hält Sie davon ab, zB eine Wegwerf-VM (wie QubesOS) zu verwenden oder ein benutzerdefiniertes Skript zu verwenden, das einige der Vorschläge aus diesem Thread implementiert. Wir sollten wohl rechthaberischer sein und QubesOS-ähnliche Funktionen in Silverblue einbauen.

Aber trotzdem ist die vorhandene VM- und Container-Technologie vorhanden. Tatsächlich ist toolbox heute wirklich ein Haufen von Skripten, die podman absichtlich mit dem Host verschwimmen lassen. Wenn Sie die Integration nicht wünschen, können Sie mit podman run da dies die Standardeinstellung ist.

@cgwalters Ich habe mit der Verwendung von Chrome OS auf meinem persönlichen Laptop begonnen und die Sicherheit zu schätzen Crostini- Projekt in einem Container in einer VM
URL
Ich habe ähnliche Lösungen evaluiert, die ich stattdessen auf meinem Arbeitslaptop verwenden kann. Eine Option wäre Cloudready von Neverware – ein Open-Source-Chrome-Betriebssystem für PC-Hardware. Manchmal gibt es Ports, bei denen Crostini abstürzt, Daten verloren gehen und neu gestartet werden muss. Aus diesem Grund zögere ich jetzt, ChromeOS / Crostini zu verdoppeln.

Silverblue sah auch überzeugend aus, bis ich feststellte, dass es Ubuntu-Container nicht sofort unterstützt und meine persönlichen Daten übermäßig mit Containern teilt, denen ich nicht vertrauen möchte. Ich habe mir auch Clear Linux angeschaut. Es hat das gleiche Konzept, fast alles in Containern auszuführen. Ich bin nicht begeistert von der engen Verbindung zu Intel und x86. Es ist auch nicht in erster Linie ein Desktop-Betriebssystem. Eine letzte (Standard?) Option wäre, bei Ubuntu als Desktop zu bleiben und meine Entwicklungsarbeit mehr in LXD-Container zu verlagern, die Crostini von Chrome verwendet. Ich sollte in der Lage sein, LXD-Container zwischen meinem Arbeits- und meinem privaten Laptop zu kopieren, obwohl das Host-Betriebssystem unterschiedlich ist. Mit LXD-Vorlagen sollte ich in der Lage sein, eine Vorlage einzurichten, die genügend Mounts in die Container für die Wayland-Unterstützung freigibt.

Randnotiz: Danke für all die Jahre der Pflege von Rhythmbox!

Vielleicht verstehe ich die Mission von toolbox falsch. Aus der README:

.. Diese Systeme sollen die Installation von Software auf dem Host verhindern

Wieso den? Standardmäßig werden alle Ihre persönlichen Daten standardmäßig in den Container geteilt. Ich glaube nicht, dass eine verbesserte Sicherheit beansprucht werden kann.

Der verbleibende potenzielle Vorteil wäre die Isolierung, sodass Sie widersprüchliche Versionen von Software nebeneinander installieren könnten.

Wenn das Always-Share-Verhalten weiterhin besteht, könnte es hilfreich sein, die Dokumentation zu aktualisieren, um zu klären, dass toolbox Ihr gesamtes Home-Verzeichnis in die Container teilt, dass das Verhalten nicht deaktiviert werden kann und nicht mit nicht vertrauenswürdigen Benutzern verwendet werden sollte Behälter.

Ich verstehe, dass ich podman direkt verwenden kann, aber mich interessierte eine Containerlösung mit GUI-Integration. Wenn Sie suchen, wie Sie dies mit podman , ist die Verwendung von toolbox der empfohlene Ansatz:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

@markstos Wenn Sie interessiert sind, habe ich PR #298 erstellt, das ein Ubuntu 19.04-Image erstellt.

Ich denke, hier herrscht einige Verwirrung.

Unser README.md ist im Laufe der Monate ein wenig gewachsen und hat sich verändert und ist wahrscheinlich etwas schwerer zu fassen. Früher hieß es einfach Hacking on OSTree-based Fedoras .

Wenn Sie Silverblue (oder ein anderes OSTree-basiertes Betriebssystem) installieren, wird die Schwierigkeit, das Betriebssystem zu debuggen oder eine Entwicklungsumgebung einzurichten, sofort offensichtlich. Toolbox existiert, um dieses Problem zu lösen.

.. Diese Systeme sollen die Installation von Software auf dem Host verhindern

Wieso den? Standardmäßig werden alle Ihre persönlichen Daten standardmäßig in den Container geteilt
glaube nicht, dass verbesserte Sicherheit beansprucht werden kann.

Sicherheit ist ein überladenes Wort. Toolbox erhebt keine Ansprüche darüber.

Über viele Jahrzehnte hinweg könnte jeder Prozess, der als Ihre UID ausgeführt wird, Ihre privaten kryptografischen Schlüssel, Dokumente, Fotos usw. einsehen und sogar um die halbe Welt übertragen, ohne dass Sie es jemals wissen. Dies ist der Status Quo von Client-Betriebssystemen für freie Software.

Flatpak ändert dies, indem es jede grafische Anwendung und das Betriebssystem in ihre eigenen Sicherheitsdomänen aufteilt. Silverblue festigt diese Trennung, indem es die Installation von Software direkt im Host-Betriebssystem-Image erschwert. Für eine reibungslose Benutzererfahrung müssen Sie also wirklich Anwendungen verwenden, die als Flatpaks ausgeliefert werden.

Wie ich jedoch oben erwähnt habe, weist dieses gesperrte Betriebssystemabbild seine eigenen Probleme auf. Wie wir sie lösen, ist ein Kompromiss zwischen Komfort und Sicherheit. Je radikaler die Lösung, desto schwieriger wäre es für bestehende Linux-Benutzer, Silverblue zu übernehmen.

Im Moment tendiert Toolbox eher zur Akzeptanz als zur Sicherheit; denn unabhängig davon, ob Sie Toolbox verwenden oder nicht, Silverblue verbessert den Zustand von Client-Betriebssystemen für freie Software erheblich und es wäre ein positiver Schritt, dies in die Hände der Benutzer zu legen.

Außerdem geht es nicht nur um die Sicherheit. Es geht auch um Stabilität.

Es ist sehr schwierig, eine herkömmliche Linux-Distribution zu testen. Pakete und Spiegel werden ständig von zufälligen Mitwirkenden auf zufälligen Spiegeln auf der ganzen Welt aktualisiert - die kombinatorische Explosion kann nur durch ein ausgeklügeltes System von Einfrieren verwaltet werden. Wenn etwas schief geht, und dies geschieht, ist es für einen Benutzer auch sehr schwierig, ein Update rückgängig zu machen, und Dinge wie Stromausfälle während eines Updates können das System unwiederbringlich beschädigen.

Ein OSTree-basiertes Betriebssystem ändert all das.

Ich verstehe, dass ich podman direkt verwenden kann, aber ich war an einer Containerlösung mit GUI interessiert
Integration. Wenn Sie suchen, wie Sie dies mit Podman erreichen können, ist die Verwendung der Toolbox
die empfohlene Vorgehensweise:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

Die Frage ist, warum Sie Podman verwenden möchten, um grafische Anwendungen auszuführen? :)

Im Allgemeinen ist Podman (oder ein OCI-Container) eine schlechte Option zum Ausführen von GUI-Apps. Das ist der ganze Grund, warum es Flatpak gibt und Toolbox konkurriert damit nicht.

Es gibt jedoch eine Überschneidung in dem Sinne, dass Toolbox-Container eine gewisse Desktop-Integration aufweisen, und es gibt einige Fälle, in denen die Möglichkeit, eine Nicht-Flatpaked-GUI-App auszuführen, kurzfristig immens nützlich ist. Es kann sein, dass die gewünschte Anwendung noch nicht Flatpaked ist oder der Flatpaked-Version einige Funktionen fehlen. Möglicherweise arbeiten Sie an einer Bibliothek, die von grafischen Anwendungen verwendet wird, und möchten schnell ein einmaliges Testprogramm ausführen, um zu sehen, ob Ihre Bibliothek wie erwartet funktioniert.

Toolbox kann in solchen Fällen tatsächlich helfen, aber das ist etwas anderes als zu sagen, dass Toolbox das primäre Ziel ist, grafische Anwendungen zu containerisieren. Das Hauptziel von Toolbox besteht darin, dass Sie Ihr Hacking auf einem OSTree-basierten Betriebssystem durchführen können.

Wenn Sie nun eine containernative IDE wie GNOME Builder verwenden , die als Flatpak geliefert wird und automatisch einen Container zum Erstellen und Ausführen der Software einrichtet, an der Sie arbeiten, dann benötigen Sie Toolbox überhaupt nicht.

Allerdings verwendet nicht jeder GNOME Builder, und die beliebtesten IDEs wie Visual Studio Code sind nicht so containernativ. Daher Toolbox.

@debarshiray Danke für die durchdachte und gründliche Antwort. Das obige Beispiel war nicht für grafische Apps, die von Flatpak abgedeckt werden könnten. Ich habe das Beispiel für die Entwicklung von Node.js gegeben. In der Node.js-Abhängigkeitskette gab es kürzlich echte Malware, die aus einer lokalen Krypto-Wallet stehlen könnte. SSH-Schlüssel könnten genauso leicht gestohlen werden. Während die README sagt, dass das Projekt auf Entwickler abzielt, schützt die standardmäßige Freigabe mit Containern Entwickler nicht vor dieser Art von Angriff.

Toolbox bietet keine Sicherheit vor dem Diebstahl persönlicher Dateien, wenn die CLI-Entwicklung mit nicht vertrauenswürdigen Abhängigkeiten durchgeführt wird. Angesichts der Komplexität moderner Open-Source-Software gibt es bestimmte Teile des Abhängigkeitsbaums, denen man nicht vertrauen sollte.

Ich finde die aktuelle README-Datei irreführend: Das Ausführen von "vollständig unprivilegiert in einem Container" klingt nach Sicherheit, aber es ist nur ein Sicherheitstheater - alle persönlichen Dateien sind im Container zugänglich. Oben erklären Sie, dass Toolbox keine Sicherheitsansprüche erheben will. Ich denke, dies wäre eine nützliche Aussage, die in die README-Datei aufgenommen werden sollte, um zu verdeutlichen, dass dies trotz der Verwendung von Containern ein Werkzeug der Bequemlichkeit und nicht der Sicherheit ist.

@debarshiray Danke für die durchdachte und gründliche Antwort. Das Beispiel, das ich gegeben habe
oben war nicht für grafische Apps, die von Flatpak abgedeckt werden könnten. Ich habe das gegeben
Beispiel für die Entwicklung von Node.js. In Node.js gab es kürzlich echte Malware
Abhängigkeitskette, die von einer lokalen Krypto-Wallet stehlen könnte. SSH-Schlüssel könnten gestohlen werden
genauso einfach. Während in der README steht, dass das Projekt auf Entwickler abzielt, ist die
share-with-containers-by-default schützt Entwickler nicht vor dieser Art von Angriff.

Ja, im Moment versucht Toolbox lediglich, die traditionelle paketbasierte Umgebung innerhalb eines Image-basierten Betriebssystems zu reproduzieren.

Ich finde die aktuelle README irreführend: Ausführen "vollständig unprivilegiert in einem Container"
Klingt nach Sicherheit, ist aber nur ein Sicherheitstheater – auf alle persönlichen Dateien kann zugegriffen werden
der Kontainer. Oben erklären Sie, dass Toolbox keine Sicherheitsansprüche erheben will.
Ich denke, das wäre eine nützliche Aussage in die README aufzunehmen, um zu verdeutlichen, dass trotz
die Verwendung von Containern, dies ist ein Werkzeug für die Bequemlichkeit und nicht für die Sicherheit.

Commit c047659c1d85ca982374da5c58ee7a24ba3847bd ist dort, wo diese Zeile hinzugefügt wurde. Ich glaube, @cwalters wollte sagen, dass Sie nur Zugriff auf Ihre eigene UID in einem Toolbox-Container haben und die echte Root (dh UID 0 auf dem Host) weder beteiligt noch für Sie verfügbar ist.

Auch ich habe das gleiche Problem. Ich habe Silverblue in der Hoffnung installiert, dass ich Software ausführen kann, der ich möglicherweise nicht ganz vertraue, ohne befürchten zu müssen, dass sie meine SSH-Schlüssel und andere sensible Informationen stiehlt.

Die Erkenntnis, dass mir die Toolbox dies nicht erlaubt, war eine große Enttäuschung und hat mich dazu veranlasst, die Verwendung von Silverblue von vornherein zu überdenken. Ich persönlich interessiere mich nicht für die Hauptinstallation des Betriebssystems. Das kann ich immer wieder neu installieren. Die Informationen, die ich wirklich getrennt halten möchte, befinden sich in meinem Home-Verzeichnis.

Wäre es möglich, genauer anzugeben, welche Teile des Home-Verzeichnisses gemeinsam genutzt werden? Wenn man nur die Verzeichnisse auf die Whitelist setzen könnte, die von der Toolbox benötigt werden (wahrscheinlich diejenigen, die sich auf die Desktop-Konfiguration usw. beziehen), würde dies viele Probleme lösen.

Jetzt bin ich mir der Probleme mit der Sicherheit vollkommen bewusst. Da ich Qubes OS seit mehreren Jahren verwende, ist das Problem der Isolation ein schwieriges. Selbst wenn Sie das Home-Verzeichnis schützen, wird dies nicht ausreichen, da ein Programm, das in einem Container ausgeführt wird, immer andere Kommunikationsmittel zwischen Containern nutzen kann, beispielsweise die Zwischenablage. Ich bin mir dessen bewusst, und ich bin bereit, einige dieser Risiken im Austausch für die Bequemlichkeit einer Toolbox im Vergleich zu einer vollständigen Qubes-Installation in Kauf zu nehmen.

Eine Problemumgehung wird hier veröffentlicht .

Der Workaround nutzt die Tatsache, dass toolbox als Bash-Skript implementiert ist, das in allen Fällen, in denen der Pfad von /home/user nachgeschlagen werden muss, auf die Umgebungsvariable $HOME verweist. Wenn Sie also die Umgebungsvariable $HOME für einen bestimmten Aufruf auf toolbox wird ein anderes Verzeichnis als Ihr gesamtes Home-Verzeichnis voller wertvoller persönlicher Dateien mit einem potenziell nicht vertrauenswürdigen Container geteilt.

Auf dieser Grundlage scheint es, dass Sie ein leeres Verzeichnis freigeben könnten, das nur die Toolbox-Konfiguration enthält, indem Sie Toolbox mit einem Wrapper wie folgt starten:

#!/bin/bash
mkdir -p ~/toolboxes
HOME=~/toolboxes "$@"'

Wenn dieses Skript toolbox heißen würde und Ihren $PATH vor dem System toolbox eingeben würde, dann scheint es dieses Problem zu lösen. Diese Lösung ist ungetestet.

Diese Funktion funktioniert jetzt im tlbx Fork: https://gitlab.com/uppercat/tlbx/issues/3

Auch ich habe das gleiche Problem. Ich habe Silverblue installiert in der Hoffnung, dass ich es schaffen würde
Software laufen lassen, der ich vielleicht nicht ganz vertraue, ohne befürchten zu müssen, dass sie mein SSH stiehlt
Schlüssel und andere sensible Informationen.

Ähm... das scheint irreführend. Wenn Sie als Benutzer nicht vertrauenswürdige Software ausführen möchten, reduziert Flatpak bereits Ihre Sorgen über den Verlust sensibler Informationen. Wenn Sie isolierte Entwicklungsumgebungen wünschen, ist das eine andere Sache.

Außerdem ist nichts davon in irgendeiner Weise Silverblue-spezifisch. Die Probleme bestehen seit Jahrzehnten und die Lösungen sind nicht Silverblue-spezifisch – sie funktionieren auch auf traditionellen paketbasierten Betriebssystemen.

Der Workaround nutzt die Tatsache aus, dass toolbox als Bash-Skript implementiert ist, das
referenziert die Umgebungsvariable $HOME in allen Fällen, in denen der Pfad von /home/user
muss nachgeschaut werden. Setzen Sie also die Umgebungsvariable $HOME für ein bestimmtes
Aufruf an toolbox verursacht ein anderes Verzeichnis als Ihr gesamtes Home-Verzeichnis voller wertvoller
persönliche Dateien, die mit einem potenziell nicht vertrauenswürdigen Container geteilt werden sollen.

Ja, das ist ein netter Hack. :)

Das primäre Ziel des Toolbox-Projekts ist es jedoch, die Einrichtung verschiedenster Entwicklungsumgebungen auf Image-basierten (insbesondere OSTree-basierten) Betriebssystemen mit etwa dem gleichen Aufwand zu ermöglichen, der auf ihren paketbasierten Pendants erforderlich ist. Diese Entwicklungsumgebungen sicherer zu machen, ist definitiv ein berechtigter Wunsch, aber es steht nicht auf der unmittelbaren To-Do-Liste, da das Problem nicht neu ist und schon seit Ewigkeiten besteht.

Auch bei Silverblue geht es nicht unbedingt um Sicherheit. Ich sehe es eher als Verbesserung der Stabilität und Robustheit des Betriebssystems. Es fördert jedoch die Verwendung von Flatpaks, sodass es in diesem Sinne indirekt die Sicherheit verbessert.

Daher ist es sinnvoll, die Funktionsparität mit paketbasierten Linux-Distributionen sicherzustellen, auch wenn einige der bestehenden Probleme beibehalten werden. Es ist besser, einige Probleme zu lösen und die Lösungen der bestehenden Benutzerbasis zugänglich zu machen, als nichts zu lösen. :)

Ich werde dieses Problem schließen, damit die Liste der offenen Probleme nicht außer Kontrolle gerät und weiterhin grob die Elemente widerspiegelt, die auf der aktuellen To-Do-Liste stehen. Es wird jedoch immer noch für zukünftige Referenzen verfügbar sein.

Ich stimme jedoch zu, dass unser README.md einfacher zu lesen sein sollte.

Hm, das Argument verstehe ich nicht. Nur weil ein Problem alt ist und schon ewig da ist, einfach nicht lösen?? Das ist IMHO keine gute Sicht.
Und wie Sie sagen, flatpak macht das: Es verbessert Schritt für Schritt die Sicherheit und isoliert Anwendungen. Sie sagten auch nicht "hmm, wir haben Apps für immer als RPM-Pakete ausgeliefert, warum sollten wir dieses Problem lösen?", sie haben es einfach gelöst.

Ich sehe keinen Grund, warum Toolbox nicht zumindest das Home-Verzeichnis isolieren sollte. Ich denke also, die Diskussion kann trotzdem in https://github.com/containers/toolbox/issues/348 fortgesetzt werden.

Ich denke, die Mitwirkenden und Betreuer von Toolbox nehmen diesen Thread als eine Beleidigung der Idee und der Arbeit, die in das Projekt gesteckt wird. Ich denke, es sollte als ein Feature angesehen werden, das von vielen Menschen benötigt wird, die von der Idee begeistert sind. Ich habe nicht den Widerstand, an einer Funktion zu arbeiten, die es Ihnen ermöglicht, ein anderes Arbeitsverzeichnis als $HOME zu mounten. Es ist eine Funktion, die die Funktionalität und den Anwendungsfall erheblich verbessern könnte, was auch die Akzeptanz und das Interesse verbessert.

Ich war derjenige, der vorgeschlagen hat, die Variable $HOME in #348 zu ändern. Dies ist eine hackige Lösung, da sie Probleme verursacht, wenn Sie mit zwei mehreren Containern mit unterschiedlichen $HOME-Verzeichnissen arbeiten möchten. Meine Befürchtung ist sogar, dass dies nicht funktioniert, wenn die Toolbox mit go neu geschrieben wird.

Viele Leute fragen nach dieser Funktion und es ist für viele zu einer Eintrittsbarriere geworden, Toolboxen, rpm-ostree und silverblue zu übernehmen. Auch wenn es nicht um Sicherheit geht, ist es ein Feature, das viele Möglichkeiten für die Arbeit mit Toolboxen eröffnen wird.

Ich bin bereit, bei diesem Problem zu helfen, wenn ich kann, und ich denke, andere werden auch bereit sein. Ich hoffe, dass diese Funktion nicht zu einem Streitpunkt wird und in zukünftigen Toolbox-Versionen nicht berücksichtigt wird. Es ist meiner Meinung nach das einzige, was derzeit noch fehlt. Es wäre, als würde man bei einem Marathon einen dnf bekommen, weil man die letzten 10 Meter beendet hat. (Wortspiel beabsichtigt :))

Es war ein Deal-Breaker für mich. Ich habe Toolbox und Silverblue danach aufgegeben
diesen Fehler finden.

Nur weil ein Problem alt ist und schon immer da ist,
einfach nicht lösen?? Das ist IMHO keine gute Sicht.

Etwas nicht auf der unmittelbaren To-Do-Liste zu haben, ist nicht dasselbe wie es nicht zu lösen . Es gibt so etwas wie Priorität .

Und wie Sie sagen, flatpak macht das: Es verbessert Schritt für Schritt die Sicherheit und
isoliert Anwendungen. Sie sagten auch nicht "hmm, wir haben Apps als ausgeliefert"
RPM-Pakete für immer, warum sollten wir dieses Problem lösen?", sie haben es einfach getan
löse es.

Ich liebe deine Verwendung des Wortes sie .

Okay, schön, wenn ich das richtig interpretiere, ist das vielleicht noch eine Idee für die Zukunft, nur nicht auf deiner "Sofort-To-Do-Liste"? (obwohl ich vermute, dass es einfach zu implementieren ist, besonders wenn Sie nur einige Patches aus einer Gabel herauspicken können )*

Wenn ja, lassen Sie dieses Problem vielleicht einfach offen und markieren Sie es als "Hilfe gesucht" – obwohl Sie nicht wirklich Hilfe benötigen, keine Ahnung… was hindert Sie daran, dies zu implementieren? Ich denke, Sie müssen nur sagen, dass Sie PRs zu diesem Thema akzeptieren und es wird implementiert.
Ich sehe nichts, was Sie davon abhält – und Sie können immer noch Feature-Parität oder so erreichen, was auch immer… es ist wirklich nur ein kleines Feature. :Denken:

* Ja, ich sehe und weiß, dass dies jetzt in Go neu geschrieben wurde, aber vielleicht hilft das immer noch oder so – keine Ahnung. Zumindest zeigt es, dass es einfach zu implementieren ist.

Dieses Thema hier ein wenig entführen, falls einer der Teilnehmer meinen Prototyp überprüfen und Feedback zu meinem Prototyp geben möchte unter https://gitlab.com/bkhl/etui

Es ist als Alternative zu Toolbox gedacht, wenn Sie einen strengeren Entwicklungscontainer wünschen.

@bkhl Danke! Mit Lesezeichen versehen.