Toolbox: Lingkungan pengembangan yang terisolasi untuk melawan bug dan malware dalam kode yang sedang dikembangkan

Anda ingin wadah pengguna persisten tanpa /home Anda? Hanya mencoba memahami persyaratan/usecase dengan lebih baik. - Katakanlah dibandingkan dengan hanya menjalankan wadah Fedora sekali pakai standar?

Pertimbangkan akun Unix yang digunakan untuk rumah dan kantor. Untuk wadah kerja, saya mungkin lebih suka memasang hanya direktori kerja saya ke dalam wadah.

Pertimbangkan aplikasi GUI yang tidak tepercaya. Mungkin hanya perlu akses ke folder tertentu untuk memuat/menyimpan file. Itu tidak memerlukan akses ke folder .ssh saya dan file lain yang tidak terkait.

Untuk meningkatkan keamanan, Chrome OS tidak membagikan folder ke container secara default dari host. Di sana, jika Anda ingin memberikan data ke wadah dari direktori home Anda atau dari drive USB, Anda secara eksplisit membagikannya.

Kontainerisasi sebagai fitur keamanan kehilangan nilai yang signifikan jika Anda memberikan semua data Anda secara default kepada penampung yang tidak tepercaya!

@juhp Saya melihat Anda bekerja dengan baik dengan paket Haskell. Anggap salah satu paket Haskell yang Anda instal dari jarak jauh telah disusupi. Apakah paket Haskell memerlukan akses ke folder .ssh atau dompet Bitcoin Anda? Mengapa membagikan semuanya ke lingkungan pengembang Haskell Anda secara default?

Baru-baru ini ada modul NPM yang masih bisa lokal Bitcoin jika dipasang:
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

Modul ini populer dan sebenarnya tim saya telah memasangnya di pohon kami. Kami tidak memenuhi kriteria lain untuk memicu pencurian bitcoin, tetapi risiko itu akan sepenuhnya dikurangi jika lingkungan pengembang kami tidak memiliki akses lengkap ke direktori rumah kami secara default. Tidak ada karyawan yang akan memilih untuk membagikan dompet Bitcoin mereka ke dalam lingkungan pengembangan ini.

Ini benar-benar valid tetapi akan sulit.

Secara praktis, saya pikir jalan terbaik adalah membuatnya mudah untuk menjalankan kotak alat sebagai pengguna yang terpisah (untuk sementara membuat uid baru, masing-masing dengan /home ) - memerlukan layanan sistem istimewa untuk melakukan itu.

Sekarang jika Anda ingin berbagi beberapa file misalnya read-only - itu menjadi lebih berantakan.

Apakah mungkin untuk mengecualikan file/dir dari direktori bind-mount?

Untuk memastikan saya memahami tantangannya, saya melihat bahwa pemasangan direktori home terjadi dalam satu baris kode

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

Namun tantangannya di sini masih membuat aplikasi GUI dan beberapa fitur lainnya berfungsi, karena fitur tersebut mengharapkan pengguna di dalam dan di luar wadah sama?

Ini sebenarnya fitur yang agak penting. Saya pikir tidak apa-apa untuk memasang rumah secara default, tetapi seharusnya dimungkinkan untuk menggunakan wadah dengan cara yang tidak tepercaya. Memasang rumah ke dalam wadah mengasumsikan Anda memercayai wadah, yang dalam wadah sekali pakai sering kali tidak demikian. Bahkan dalam kasus sederhana seperti menguji beberapa modul NPM, saya ingin memiliki ketenangan pikiran bahwa itu tidak akan merusak folder rumah saya.

@markstos mungkin Anda dapat menguji apa yang dapat Anda lakukan tanpa pemasangan di rumah atau jika hanya memasang dir (cwd) tertentu?

@juhp Sebenarnya ini adalah showstopper untuk saya-- Saya berhenti mengevaluasi Silverblue setelah saya mengalami fitur yang hilang ini. Jika ini ditangani, saya dapat memberikan Silverblue pandangan kedua. Saya juga kecewa mengetahui bahwa tidak mudah untuk mengetahui cara menjalankan wadah Ubuntu, yang merupakan OS yang telah saya gunakan sebelumnya.

Jika Fedora ingin menyambut pengguna yang datang dari distro Linux lain, membuatnya mudah untuk menjalankan distro lama mereka dalam wadah akan menjadi tempat yang baik untuk memulai.

@markstos terima kasih - Saya hanyalah pengguna Toolbox lainnya. :-)
Saya setuju sepenuhnya bahwa memperluas Toolbox untuk mendukung lebih banyak OS akan sangat berguna.
Perhatikan bahwa Toolbox juga berfungsi tanpa Silverblue (yaitu pada edisi Fedora lainnya).

@juhp Sebenarnya ini adalah showstopper bagi saya-- Saya berhenti mengevaluasi Silverblue setelah saya mengalami fitur yang hilang ini

Apa yang Anda lakukan sebelumnya? Apakah ada alat/pendekatan lain yang Anda gunakan yang tidak berfungsi di Silverblue?

Tidak ada yang menghentikan Anda dari misalnya menggunakan VM sekali pakai (seperti QubesOS), atau dalam hal ini memiliki skrip khusus yang mengimplementasikan beberapa saran dari utas ini. Boleh dibilang, kita harus lebih berpendirian dan membangun fungsionalitas seperti QubesOS ke dalam Silverblue.

Tapi bagaimanapun juga ada VM dan teknologi container yang ada. Sebenarnya toolbox hari ini benar-benar sekumpulan skrip yang membuat podman sengaja diburamkan dengan host. Jika Anda tidak menginginkan integrasi, Anda dapat memulai dengan podman run ... karena itulah defaultnya.

@cgwalters Saya sudah mulai menggunakan Chrome OS di laptop pribadi saya dan mulai menghargai keamanan lingkungan pengembangan saya (dan hampir semua yang lain) berjalan dalam wadah di VM melalui proyek Crostini . Saya suka itu mendukung aplikasi GUI serta aplikasi baris perintah. Saya juga suka bahwa wadah bersifat pribadi secara default. Saya harus secara eksplisit membagikan folder data atau drive USB dengan mereka. Di sisi lain, dukungan suara dan wayland secara otomatis diatur dalam wadah tersebut.
url
Saya telah mengevaluasi solusi serupa untuk digunakan pada laptop kerja saya. Salah satu opsinya adalah Neverware's Cloudready-- Chrome OS open source untuk perangkat keras PC. Terkadang ada port yang Crostini crash, data hilang dan perlu memulai dari awal. Untuk alasan itu, saya ragu untuk menggandakan ChromeOS / Crostini sekarang.

Silverblue juga tampak menarik sampai saya merasa tidak mendukung wadah Ubuntu di luar kotak dan membagikan data pribadi saya secara berlebihan dengan wadah yang tidak ingin saya percayai. Saya juga melihat Clear Linux. Ini memiliki konsep yang sama untuk menjalankan hampir semua hal dalam wadah. Saya tidak senang dengan hubungan dekat dengan Intel dan x86. Ini juga bukan OS desktop. Opsi terakhir (default?) adalah tetap menggunakan Ubuntu sebagai desktop dan memindahkan lebih banyak pekerjaan pengembangan saya ke wadah LXD, yang digunakan oleh Chrome's Crostini. Saya harus dapat menyalin wadah LXD antara pekerjaan dan laptop pribadi saya meskipun OS Host berbeda. Dengan menggunakan templat LXD, saya harus dapat mengatur templat yang membagikan cukup banyak tunggangan ke dalam wadah untuk dukungan Wayland.

catatan samping: Terima kasih untuk semua tahun mempertahankan Rhythmbox!

Mungkin saya salah memahami misi toolbox . Dari README:

.. Tujuan dari sistem ini adalah untuk mencegah instalasi perangkat lunak pada host

Mengapa? Dengan default adalah membagikan semua data pribadi Anda ke dalam wadah secara default, saya rasa keamanan yang ditingkatkan tidak dapat diklaim.

Manfaat potensial yang tersisa adalah isolasi, sehingga Anda dapat menginstal versi perangkat lunak yang saling bertentangan secara berdampingan.

Jika perilaku selalu bagikan tetap ada, akan sangat membantu untuk memperbarui dokumen yang mengklarifikasi bahwa toolbox membagikan seluruh direktori beranda Anda ke dalam wadah, bahwa perilaku tersebut tidak dapat dinonaktifkan dan tidak boleh digunakan dengan yang tidak dipercaya kontainer.

Saya mengerti bahwa saya dapat menggunakan podman secara langsung, tetapi saya tertarik dengan solusi wadah dengan integrasi GUI. Saat mencari tentang cara mencapainya dengan podman , menggunakan toolbox adalah pendekatan yang disarankan:

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

@markstos Jika Anda tertarik, saya telah membuat PR #298 yang membangun gambar Ubuntu 19.04.

Saya pikir ada beberapa kebingungan di sini.

README.md telah tumbuh dan berubah sedikit selama beberapa bulan, dan mungkin sedikit lebih sulit untuk dipahami. Sebelumnya hanya mengatakan Peretasan pada Fedoras berbasis OSTree .

Jika Anda menginstal Silverblue (atau OS berbasis OSTree lainnya dalam hal ini), kesulitan men-debug OS atau menyiapkan lingkungan pengembangan menjadi segera terlihat. Toolbox ada untuk memecahkan masalah itu.

.. Tujuan dari sistem ini adalah untuk mencegah instalasi perangkat lunak pada host

Mengapa? Dengan default adalah membagikan semua data pribadi Anda ke dalam wadah secara default, saya
tidak berpikir peningkatan keamanan dapat diklaim.

Keamanan adalah kata yang berlebihan. Toolbox tidak membuat klaim apa pun tentangnya.

Selama beberapa dekade, proses apa pun yang berjalan sebagai UID Anda dapat melihat kunci kriptografis pribadi Anda, dokumen, foto, dll. dan bahkan mengirimkannya setengah jalan melintasi planet ini tanpa Anda sadari. Ini adalah status quo dari OS klien perangkat lunak bebas.

Flatpak mengubahnya dengan memisahkan setiap aplikasi grafis dan sistem operasi ke dalam domain keamanan mereka sendiri. Silverblue memperkuat pemisahan ini dengan mempersulit pemasangan perangkat lunak langsung di dalam citra OS host. Jadi, untuk pengalaman pengguna yang lancar, Anda benar-benar perlu menggunakan aplikasi yang dikirimkan sebagai Flatpaks.

Namun, seperti yang saya sebutkan di atas, gambar OS yang dikunci ini menghadirkan serangkaian masalahnya sendiri. Cara kami mengatasinya adalah trade-off antara kenyamanan dan keamanan. Semakin radikal solusinya, semakin sulit bagi pengguna Linux yang ada untuk mengadopsi Silverblue.

Saat ini, Toolbox condong ke arah adopsi daripada keamanan; karena terlepas dari apakah Anda menggunakan Toolbox atau tidak, Silverblue membuat peningkatan kuantum dalam keadaan OS klien perangkat lunak bebas dan memasukkannya ke tangan pengguna akan menjadi langkah positif.

Plus, ini bukan hanya tentang keamanan. Ini juga tentang stabilitas.

Sangat sulit untuk menguji distribusi Linux konvensional. Paket dan cermin selalu diperbarui oleh kontributor acak pada cermin acak di seluruh dunia - ledakan kombinatorial hanya dapat dikelola oleh sistem pembekuan yang rumit. Ketika terjadi kesalahan, dan memang demikian, sangat sulit bagi pengguna untuk mengembalikan pembaruan, dan hal-hal seperti pemadaman listrik di tengah pembaruan dapat merusak sistem yang tidak dapat diperbaiki.

OS berbasis OSTree mengubah semua itu.

Saya mengerti bahwa saya dapat menggunakan podman secara langsung, tetapi saya tertarik dengan solusi wadah dengan GUI
integrasi. Saat mencari cara melakukannya dengan podman, menggunakan kotak alat adalah
pendekatan yang disarankan:

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

Pertanyaannya adalah mengapa Anda ingin menggunakan Podman untuk menjalankan aplikasi grafis? :)

Secara umum, Podman (atau wadah OCI) adalah opsi yang buruk untuk menjalankan aplikasi GUI. Itulah alasan mengapa Flatpak ada dan Toolbox tidak bersaing dengan itu.

Namun, ada tumpang tindih, dalam arti bahwa wadah Toolbox memang memiliki beberapa integrasi desktop, dan ada beberapa kasus di mana kemampuan untuk menjalankan aplikasi GUI non-Flatpaked sangat berguna dalam jangka pendek langsung. Bisa jadi aplikasi yang Anda inginkan belum Flatpaked, atau mungkin versi Flatpakednya kekurangan beberapa fitur. Bisa jadi Anda sedang mengerjakan beberapa pustaka yang digunakan oleh aplikasi grafis, dan Anda ingin menjalankan program pengujian satu kali dengan cepat untuk melihat apakah pustaka Anda berfungsi seperti yang diharapkan.

Toolbox memang dapat membantu dalam kasus seperti itu, tetapi itu berbeda dengan mengatakan bahwa tujuan utama Toolbox adalah untuk menampung aplikasi grafis. Tujuan utama Toolbox adalah untuk memungkinkan Anda menyelesaikan peretasan pada OS berbasis OSTree.

Sekarang, jika Anda menggunakan IDE container-native seperti GNOME Builder , yang dikirimkan sebagai Flatpak, dan secara otomatis menyiapkan container untuk membangun dan menjalankan perangkat lunak yang sedang Anda kerjakan, maka Anda tidak memerlukan Toolbox sama sekali.

Namun, tidak semua orang menggunakan GNOME Builder, dan IDE paling populer seperti Visual Studio Code bukanlah container-native seperti itu. Oleh karena itu, Kotak Alat.

@debarshiray Terima kasih atas tanggapan yang bijaksana dan menyeluruh. Contoh yang saya berikan di atas bukan untuk aplikasi grafis yang mungkin dicakup oleh Flatpak. Saya memberi contoh melakukan pengembangan Node.js. Baru-baru ini ada malware nyata dalam rantai ketergantungan Node.js yang dapat mencuri dari dompet kripto lokal. Kunci SSH dapat dicuri dengan mudah. Sementara README mengatakan bahwa proyek tersebut menargetkan pengembang, share-with-containers-by-default tidak mengamankan pengembang dari serangan semacam itu.

Toolbox tidak memberikan keamanan dari pencurian file pribadi saat melakukan pengembangan CLI dengan dependensi yang tidak tepercaya. Mengingat kompleksitas perangkat lunak open source modern, pasti ada beberapa bagian dari pohon ketergantungan yang tidak boleh dipercaya.

Saya menemukan README saat ini menyesatkan: Menjalankan "sepenuhnya tidak memiliki hak istimewa dalam wadah" terdengar seperti keamanan, tetapi itu hanya teater keamanan-- semua file pribadi dapat diakses dalam wadah. Di atas Anda mengklarifikasi bahwa Toolbox tidak bermaksud membuat klaim tentang keamanan. Saya pikir itu akan menjadi pernyataan yang berguna untuk disertakan dalam README untuk mengklarifikasi bahwa meskipun menggunakan wadah, ini adalah alat untuk kenyamanan bukan keamanan.

@debarshiray Terima kasih atas tanggapan yang bijaksana dan menyeluruh. Contoh yang saya berikan
di atas bukan untuk aplikasi grafis yang mungkin dicakup oleh Flatpak. saya memberi
contoh melakukan pengembangan Node.js. Baru-baru ini ada malware nyata di Node.js
rantai ketergantungan yang dapat mencuri dari dompet kripto lokal. Kunci SSH bisa dicuri
dengan mudah. Sementara README mengatakan proyek menargetkan pengembang,
share-with-containers-by-default tidak mengamankan pengembang dari serangan semacam itu.

Ya, saat ini Toolbox hanya mencoba mereproduksi lingkungan berbasis paket tradisional dalam OS berbasis gambar.

Saya menemukan README saat ini menyesatkan: Menjalankan "sepenuhnya tidak memiliki hak istimewa dalam sebuah wadah"
terdengar seperti keamanan, tetapi ini hanya teater keamanan-- semua file pribadi dapat diakses di
wadah. Di atas Anda mengklarifikasi bahwa Toolbox tidak bermaksud membuat klaim tentang keamanan.
Saya pikir itu akan menjadi pernyataan yang berguna untuk dimasukkan dalam README untuk mengklarifikasi bahwa meskipun
penggunaan kontainer, ini adalah alat untuk kenyamanan bukan keamanan.

Komit c047659c1d85ca982374da5c58ee7a24ba3847bd adalah tempat baris itu ditambahkan. Saya percaya @cgwalters bermaksud untuk mengatakan bahwa Anda hanya memiliki akses ke UID Anda sendiri di dalam wadah kotak peralatan dan root sebenarnya (mis., UID 0 pada Host) tidak terlibat atau tersedia untuk Anda.

Saya juga memiliki masalah yang sama. Saya menginstal Silverblue dengan harapan bahwa saya akan dapat menjalankan perangkat lunak yang mungkin tidak sepenuhnya saya percayai tanpa harus khawatir bahwa itu mencuri kunci SSH saya dan informasi sensitif lainnya.

Kesadaran bahwa toolbox tidak memungkinkan saya untuk melakukan ini adalah kekecewaan besar dan telah membawa saya untuk mempertimbangkan kembali penggunaan Silverblue untuk memulai. Secara pribadi, saya tidak peduli dengan instalasi OS utama. Saya selalu dapat menginstal ulang itu. Informasi yang benar-benar ingin saya pisahkan terletak di direktori home saya.

Apakah mungkin untuk menentukan dengan beberapa perincian yang lebih besar secara tepat bagian mana dari direktori home yang dibagikan? Jika seseorang dapat memasukkan daftar putih hanya direktori yang dibutuhkan oleh kotak alat (mungkin yang berkaitan dengan konfigurasi desktop, dll) ini akan menyelesaikan banyak masalah.

Sekarang, saya sangat menyadari masalah keamanan. Karena saya telah menggunakan OS Qubes selama beberapa tahun, masalah isolasi adalah masalah yang sulit. Bahkan jika Anda melindungi direktori home, itu tidak akan cukup karena program yang berjalan di dalam wadah selalu dapat memanfaatkan sarana komunikasi lain antar wadah, seperti clipboard. Saya menyadari hal ini, dan saya bersedia menerima sebagian dari risiko tersebut dengan imbalan kenyamanan sesuatu seperti kotak peralatan dibandingkan dengan instalasi Qubes penuh.

Sebuah solusi diterbitkan di sini .

Solusinya memanfaatkan fakta bahwa toolbox diimplementasikan sebagai skrip bash yang mereferensikan variabel lingkungan $HOME dalam semua kasus di mana jalur /home/user perlu dicari. Jadi dengan menyetel variabel lingkungan $HOME untuk panggilan tertentu ke toolbox menyebabkan direktori aa selain seluruh direktori home Anda penuh dengan file pribadi yang berharga untuk dibagikan dengan wadah yang berpotensi tidak tepercaya.

Berdasarkan itu, tampaknya Anda dapat membagikan direktori kosong yang hanya berisi konfigurasi kotak alat dengan meluncurkan kotak alat dengan pembungkus seperti ini:

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

Jika skrip ini diberi nama toolbox dan dimasukkan ke dalam $PATH Anda di depan sistem toolbox , maka tampaknya skrip tersebut akan mengatasi masalah ini. Solusi ini belum teruji.

Fitur ini sekarang berfungsi di garpu tlbx : https://gitlab.com/uppercat/tlbx/issues/3

Saya juga memiliki masalah yang sama. Saya menginstal Silverblue dengan harapan saya bisa
menjalankan perangkat lunak yang mungkin tidak sepenuhnya saya percayai tanpa harus khawatir perangkat lunak itu mencuri SSH saya
kunci dan informasi sensitif lainnya.

Umm... ini sepertinya menyesatkan. Jika Anda ingin menjalankan perangkat lunak yang tidak tepercaya sebagai pengguna, maka Flatpak sudah mengurangi kekhawatiran Anda tentang kehilangan informasi sensitif. Jika Anda ingin lingkungan pengembangan yang terisolasi, maka itu hal yang berbeda.

Juga, semua ini tidak spesifik Silverblue dengan cara apa pun. Masalah telah ada selama beberapa dekade, dan solusinya tidak khusus untuk Silverblue - mereka juga bekerja pada OS berbasis paket tradisional.

Solusinya mengeksploitasi fakta bahwa toolbox diimplementasikan sebagai skrip bash yang
mereferensikan variabel lingkungan $HOME dalam semua kasus di mana jalur /home/user
perlu diperhatikan. Jadi dengan mengatur variabel lingkungan $HOME untuk tertentu
panggilan ke toolbox menyebabkan direktori selain seluruh direktori home Anda penuh dengan nilai
file pribadi untuk dibagikan dengan wadah yang berpotensi tidak tepercaya.

Ya, itu peretasan yang rapi. :)

Namun, tujuan utama dari proyek Toolbox adalah untuk memungkinkan pengaturan berbagai lingkungan pengembangan pada sistem operasi berbasis gambar (terutama berbasis OSTree) dengan jumlah upaya yang kira-kira sama dengan yang diperlukan pada rekan berbasis paket mereka. Membuat lingkungan pengembangan ini lebih aman jelas merupakan keinginan yang sah, tetapi itu bukan sesuatu yang harus segera dilakukan, karena masalahnya bukanlah hal baru dan telah ada sejak lama.

Juga Silverblue tidak selalu tentang keamanan. Saya melihatnya lebih sebagai peningkatan stabilitas dan ketahanan sistem operasi. Namun, itu mendorong penggunaan Flatpaks, jadi dalam artian itu secara tidak langsung meningkatkan keamanan.

Oleh karena itu, ada nilai dalam memastikan paritas fitur dengan distribusi Linux berbasis paket, bahkan jika itu mempertahankan beberapa masalah yang ada. Memecahkan beberapa masalah dan membuat solusi dapat diakses oleh basis pengguna yang ada lebih baik daripada tidak menyelesaikan apa pun. :)

Saya akan menutup masalah ini sehingga daftar masalah terbuka tidak lepas kendali, dan terus secara kasar mencerminkan item yang ada di daftar tugas saat ini. Namun, itu masih akan ada untuk referensi di masa mendatang.

Saya setuju bahwa README.md seharusnya lebih mudah dibaca.

Hmm, saya tidak mengerti argumen itu. Hanya karena masalah sudah lama dan sudah ada selamanya, tidak menyelesaikannya?? Itu bukan sudut pandang yang baik, IMHO.
Dan seperti yang Anda katakan, flatpak melakukan itu: Langkah demi langkah meningkatkan keamanan dan mengisolasi aplikasi. Mereka juga tidak mengatakan "hmm, kami telah mengirimkan aplikasi sebagai paket rpm selamanya, mengapa kami harus menyelesaikan masalah ini?", Mereka hanya menyelesaikannya.

Saya tidak melihat alasan mengapa kotak peralatan setidaknya tidak mengisolasi direktori home juga. Jadi saya kira diskusinya bisa dilanjutkan di https://github.com/containers/toolbox/issues/348 .

Saya pikir kontributor dan pengelola kotak alat menganggap utas ini sebagai bashing pada ide dan pekerjaan yang dimasukkan ke dalam proyek. Saya pikir itu harus dianggap sebagai fitur yang dibutuhkan oleh banyak orang yang tertarik dengan ide tersebut. Saya tidak mendapatkan penolakan untuk mengerjakan fitur yang memungkinkan Anda memasang direktori kerja selain $HOME. Ini adalah fitur yang dapat sangat meningkatkan fungsionalitas dan usecase yang juga akan meningkatkan adopsi dan minat.

Saya adalah orang yang menyarankan untuk mengubah variabel $HOME di #348 . Ini adalah solusi peretasan karena menyebabkan masalah ketika Anda ingin bekerja dengan dua wadah ganda dengan direktori $HOME yang berbeda. Ketakutan saya bahkan ini tidak akan berfungsi ketika kotak peralatan ditulis ulang dengan go.

Banyak orang yang meminta fitur ini dan telah menjadi penghalang masuk bagi banyak orang untuk mengadopsi toolbox, rpm-ostree dan silverblue. Bahkan jika ini bukan tentang keamanan, ini adalah fitur yang akan membuka banyak kemungkinan untuk bekerja dengan kotak peralatan.

Saya bersedia membantu dalam masalah ini jika saya bisa dan saya pikir orang lain juga akan bersedia. Saya harap fitur ini tidak menjadi bahan perdebatan dan tidak disertakan dalam rilis toolbox di masa mendatang. Menurut pendapat saya satu-satunya hal yang saat ini hilang di dalamnya. Ini akan seperti mendapatkan dnf dalam maraton karena berhenti 10 meter terakhir. (pun intended :) )

Itu adalah pemecah kesepakatan bagi saya. Saya menyerah pada kotak peralatan dan Silverblue setelahnya
menemukan kekurangan ini.

Hanya karena masalah sudah lama dan sudah ada selamanya,
hanya tidak menyelesaikannya?? Itu bukan sudut pandang yang baik, IMHO.

Tidak memiliki sesuatu di daftar tugas langsung tidak sama dengan tidak menyelesaikannya . Ada yang namanya prioritas .

Dan seperti yang Anda katakan, flatpak melakukan itu: Langkah demi langkah meningkatkan keamanan dan
mengisolasi aplikasi. Mereka juga tidak mengatakan "hmm, kami telah mengirimkan aplikasi sebagai
paket rpm selamanya, mengapa kita harus menyelesaikan masalah ini?", mereka baru saja melakukannya
menyelesaikannya.

Saya suka Anda menggunakan kata mereka .

Oke, bagus, jadi jika saya menafsirkannya dengan benar, ini mungkin masih menjadi ide untuk masa depan, hanya saja tidak ada dalam "daftar yang harus dilakukan" Anda? (meskipun saya kira itu mudah diterapkan, terutama jika Anda bisa memilih beberapa tambalan dari fork )*

Jika demikian, mungkin biarkan masalah ini tetap terbuka dan beri tag sebagai "dicari bantuan" – meskipun Anda tidak benar-benar membutuhkan bantuan, entahlah… apa yang mencegah Anda menerapkan ini? Saya kira Anda hanya perlu mengatakan bahwa Anda menerima PR tentang topik ini dan itu akan diterapkan.
Saya tidak melihat ada yang menghentikan Anda dari itu – dan Anda masih dapat mencapai paritas fitur atau lebih, apa pun… itu benar-benar hanya fitur kecil. :pemikiran:

* Ya saya melihat dan tahu ini telah ditulis ulang di Go sekarang, tapi mungkin ini masih membantu atau lebih – tidak tahu. Setidaknya itu menunjukkan bahwa itu mudah diterapkan.

Membajak masalah ini sedikit di sini jika ada peserta yang ingin memeriksa dan memberikan umpan balik tentang prototipe saya di https://gitlab.com/bkhl/etui

Ini dimaksudkan sebagai alternatif untuk Toolbox ketika Anda menginginkan wadah pengembangan yang lebih ketat.

@bkhl Terima kasih! Ditandai.