Toolbox: بيئات تطوير معزولة للحماية من الأخطاء والبرامج الضارة في التعليمات البرمجية قيد التطوير

هل تريد حاوية مستخدم ثابتة بدون منزلك /؟ مجرد محاولة لفهم الشرط / حالة الاستخدام بشكل أفضل. - قل مقارنة بتشغيل حاوية فيدورا عادية؟

ضع في اعتبارك حساب Unix الذي يتم استخدامه للمنزل والعمل. بالنسبة لحاوية العمل ، قد أفضّل تركيب دليل عملي فقط في الحاوية.

ضع في اعتبارك تطبيق واجهة مستخدم رسومية غير موثوق به. قد يحتاج فقط إلى الوصول إلى مجلد معين لتحميل / حفظ الملفات. لا يحتاج إلى الوصول إلى مجلد .ssh الخاص بي والملفات الأخرى غير ذات الصلة.

لتحسين الأمان ، لا يقوم نظام التشغيل Chrome OS بمشاركة المجلدات في الحاويات افتراضيًا من المضيف. هناك ، إذا كنت ترغب في توفير البيانات للحاويات من الدليل الرئيسي الخاص بك أو من محرك أقراص USB ، فأنت تشاركها بشكل صريح.

تفقد الحاوية كميزة أمان قيمة كبيرة إذا أعطيت الحاوية غير الموثوق بها جميع بياناتك بشكل افتراضي!

juhp أرى أنك تعمل صفقة جيدة مع حزم هاسكل. افترض أن إحدى حزم Haskell التي تقوم بتثبيتها عن بعد قد تعرضت للاختراق. هل تحتاج حزم Haskell إلى الوصول إلى مجلد .ssh أو محفظة Bitcoin الخاصة بك؟ لماذا تشارك كل شيء في بيئة تطوير Haskell بشكل افتراضي؟

في الآونة الأخيرة ، كانت هناك وحدة NPM لا يزال بإمكانها استخدام Bitcoin المحلي إذا تم تثبيتها:
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

كانت الوحدة شائعة وفي الواقع قام فريقي بتثبيتها في شجرتنا. لم نلبي المعايير الأخرى لإحداث سرقة بيتكوين ، ولكن كان من الممكن تخفيف هذا الخطر تمامًا إذا لم يكن لدى بيئة التطوير لدينا وصول كامل إلى أدلة المنزل الخاصة بنا بشكل افتراضي. لم يكن أي موظف ليختار مشاركة محفظة Bitcoin الخاصة به في بيئة التطوير هذه.

هذا صحيح تمامًا ولكنه سيكون صعبًا.

من الناحية العملية ، أعتقد أن أفضل مسار هو تسهيل تشغيل صناديق الأدوات كمستخدمين منفصلين (إنشاء /home ) - يتطلب خدمة نظام مميزة للقيام بذلك.

الآن ، إذا كنت تريد مشاركة بعض الملفات ، على سبيل المثال للقراءة فقط - فهذا يصبح أكثر تعقيدًا.

هل من الممكن استبعاد الملفات / dirs من دليل ربط جبل؟

للتأكد من فهمي للتحدي ، أرى أن تحميل الدليل الرئيسي يحدث في سطر واحد من التعليمات البرمجية

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

لكن التحدي هنا لا يزال يجعل تطبيقات واجهة المستخدم الرسومية وبعض الميزات الأخرى تعمل ، لأن هذه الميزات تتوقع أن المستخدم داخل وخارج الحاوية هو نفسه؟

هذه في الواقع ميزة مهمة إلى حد ما. أعتقد أنه من الجيد التثبيت في المنزل افتراضيًا ، ولكن يجب أن يكون من الممكن استخدام حاوية بطريقة غير موثوق بها. يفترض تركيب المنزل في حاوية أنك تثق بالحاوية ، والتي غالبًا ما لا تكون كذلك في الحاوية القابلة للتخلص منها. حتى في الحالات البسيطة مثل اختبار بعض وحدات NPM ، أود أن أشعر براحة البال لأنها لن تدمر مجلد منزلي.

markstos ربما يمكنك اختبار ما يمكنك القيام به بدون التثبيت المنزلي أو إذا كنت تقوم فقط بتركيب dir معين (cwd)؟

juhp في الواقع كان هذا أمرًا رائعًا بالنسبة لي - لقد توقفت عن تقييم Silverblue بمجرد أن واجهت هذه الميزة المفقودة. إذا تم معالجة هذا الأمر ، فقد أعطي Silverblue نظرة ثانية. شعرت بخيبة أمل أيضًا عندما اكتشفت أنه لم يكن من السهل معرفة كيفية تشغيل حاوية Ubuntu ، وهو نظام التشغيل الذي كنت أستخدمه من قبل.

إذا أراد Fedora الترحيب بالمستخدمين القادمين من توزيعات Linux الأخرى ، فإن تسهيل تشغيل توزيعة قديمة في حاوية سيكون مكانًا جيدًا للبدء.

markstos شكرًا - أنا مجرد مستخدم Toolbox آخر. :-)
أوافق تمامًا على أن توسيع Toolbox لدعم المزيد من أنظمة التشغيل سيكون مفيدًا جدًا بالفعل.
لاحظ أن Toolbox يعمل أيضًا بدون Silverblue (على سبيل المثال في إصدارات Fedora الأخرى).

juhp في الواقع كان هذا أمرًا رائعًا بالنسبة لي - لقد توقفت عن تقييم Silverblue بمجرد أن واجهت هذه الميزة المفقودة

ماذا فعلت سابقا؟ هل هناك أداة / نهج آخر كنت تستخدمه ولم ينجح في Silverblue؟

لا شيء يمنعك على الإطلاق من استخدام جهاز افتراضي يمكن التخلص منه (مثل QubesOS) ، أو في هذه المسألة وجود نص مخصص يقوم بتنفيذ بعض الاقتراحات من هذا الموضوع. يمكن القول ، يجب أن نكون أكثر رأياً وأن نبني وظائف تشبه QubesOS في Silverblue.

ولكن على أي حال ، توجد تقنية VM والحاويات الموجودة. في الواقع ، toolbox اليوم عبارة عن مجموعة من البرامج النصية التي تجعل podman ضبابيًا عمدًا مع المضيف. إذا كنت لا تريد التكامل ، يمكنك البدء بـ podman run ... لأن هذا هو الخيار الافتراضي.

cgwalters لقد بدأت في استخدام Chrome OS على الكمبيوتر المحمول الشخصي الخاص بي وأصبحت أقدر أمان بيئة التطوير الخاصة بي (وكل شيء آخر تقريبًا) تعمل داخل حاوية في VM من خلال مشروع Crostini . يعجبني أنه يدعم تطبيقات واجهة المستخدم الرسومية وكذلك تطبيقات سطر الأوامر. أحب أيضًا أن تكون الحاويات خاصة بشكل افتراضي. لا بد لي من مشاركة مجلدات البيانات أو محركات أقراص USB معهم بشكل صريح. من ناحية أخرى ، يتم إعداد دعم الصوت والمسار تلقائيًا في تلك الحاويات.
عنوان url
كنت أقوم بتقييم حلول مماثلة لاستخدامها على كمبيوتر العمل المحمول الخاص بي بدلاً من ذلك. قد يكون أحد الخيارات هو Neverware's Cloudready - نظام تشغيل Chrome مفتوح المصدر لأجهزة الكمبيوتر. في بعض الأحيان هناك منافذ يتعطل فيها Crostini ، ويتم فقد البيانات والبدء من جديد ضروري. لهذا السبب ، أتردد في مضاعفة ChromeOS / Crostini الآن.

بدا Silverblue أيضًا مقنعًا حتى وجدت أنه لا يبدو أنه يدعم حاويات Ubuntu خارج الصندوق وأنه يشارك بياناتي الشخصية مع حاويات لا أنوي الوثوق بها. نظرت أيضًا في Clear Linux. لها نفس مفهوم تشغيل كل شيء تقريبًا في الحاويات. لست سعيدًا بالعلاقات الوثيقة مع Intel و x86. إنه أيضًا ليس نظام تشغيل سطح مكتب بشكل أساسي. سيكون الخيار الأخير (الافتراضي؟) هو التمسك بـ Ubuntu كسطح مكتب ونقل المزيد من أعمال التطوير الخاصة بي إلى حاويات LXD ، والتي يستخدمها Chrome's Crostini. يجب أن أكون قادرًا على نسخ حاويات LXD بين عملي وأجهزة الكمبيوتر المحمولة الشخصية على الرغم من اختلاف نظام التشغيل المضيف. باستخدام قوالب LXD ، يجب أن أكون قادرًا على إعداد قالب يشارك عددًا كافيًا من الحوامل في الحاويات لدعم Wayland.

ملاحظة جانبية: شكرًا لجميع سنوات الحفاظ على Rhythmbox!

ربما أساء فهم مهمة toolbox . من README:

.. القصد من هذه الأنظمة هو تثبيط تثبيت البرامج على المضيف

لماذا ا؟ مع الوضع الافتراضي هو مشاركة جميع بياناتك الشخصية في الحاوية افتراضيًا ، لا أعتقد أنه يمكن المطالبة بالأمان المحسن.

ستتمثل الفائدة المحتملة المتبقية في العزلة ، لذا يمكنك تثبيت إصدارات متضاربة من البرنامج جنبًا إلى جنب.

إذا استمر سلوك المشاركة دائمًا ، فقد يكون من المفيد تحديث المستندات وتوضيح أن toolbox يشارك دليل الصفحة الرئيسية بالكامل في الحاويات ، وأن السلوك لا يمكن تعطيله ويجب عدم استخدامه مع غير موثوق به حاويات.

أدرك أنه يمكنني استخدام podman مباشرة ، لكنني كنت مهتمًا بحل حاوية مع تكامل واجهة المستخدم الرسومية. عند البحث عن كيفية تحقيق ذلك باستخدام podman ، فإن استخدام toolbox هو الأسلوب الموصى به:

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

markstos إذا كنت مهتمًا ، فقد قمت بإنشاء PR # 298 الذي ينشئ صورة Ubuntu 19.04.

أعتقد أن هناك بعض الالتباس هنا.

لقد نما README.md وتحول قليلاً على مدار الأشهر ، وربما يكون فهمه أصعب قليلاً. في وقت سابق كان يقال ببساطة

إذا قمت بتثبيت Silverblue (أو أي نظام تشغيل آخر قائم على OSTree لهذه المسألة) ، فإن صعوبة تصحيح أخطاء نظام التشغيل أو إعداد بيئة تطوير تصبح واضحة على الفور. يوجد Toolbox لحل هذه المشكلة.

.. القصد من هذه الأنظمة هو تثبيط تثبيت البرامج على المضيف

لماذا ا؟ مع الوضع الافتراضي هو مشاركة جميع بياناتك الشخصية في الحاوية افتراضيًا ، أنا
لا أعتقد أنه يمكن المطالبة بتحسين الأمن.

الأمن كلمة مثقلة. لا يقدم Toolbox أي ادعاءات حول هذا الموضوع.

لعقود عديدة ، يمكن لأي عملية تعمل كمعرف فريد خاص بك أن تنظر في مفاتيح التشفير والمستندات والصور الخاصة بك وما إلى ذلك ، بل وتنقلها في منتصف الطريق عبر الكوكب دون علمك. هذا هو الوضع الراهن لأنظمة تشغيل عميل البرامج المجانية.

يغير Flatpak ذلك عن طريق فصل كل تطبيق رسومي ونظام التشغيل إلى مجالات الأمان الخاصة بهم. يعمل Silverblue على ترسيخ هذا الفصل عن طريق جعل تثبيت البرنامج مباشرة داخل صورة نظام التشغيل المضيف أمرًا صعبًا. لذلك ، للحصول على تجربة مستخدم سلسة ، تحتاج حقًا إلى استخدام التطبيقات التي يتم شحنها على أنها Flatpaks.

ومع ذلك ، كما ذكرت في الجزء العلوي ، فإن صورة نظام التشغيل هذه المقفلة تعرض مجموعة المشاكل الخاصة بها. كيف نحلها هو مفاضلة بين الراحة والأمان. كلما كان الحل أكثر جذرية ، كان من الصعب على مستخدمي Linux الحاليين استخدام Silverblue.

في الوقت الحالي ، يميل Toolbox نحو التبني على الأمن ؛ لأنه بغض النظر عما إذا كنت تستخدم Toolbox أم لا ، فإن Silverblue يقوم بتحسين كمي في حالة أنظمة تشغيل عميل البرمجيات الحرة وسيكون الحصول على ذلك في أيدي المستخدم خطوة إيجابية.

بالإضافة إلى ذلك ، لا يتعلق الأمر بالأمن فقط. إنه يتعلق أيضًا بالاستقرار.

من الصعب جدًا اختبار توزيع Linux التقليدي. يتم دائمًا تحديث الحزم والمرايا من قبل مساهمين عشوائيين على مرايا عشوائية في جميع أنحاء العالم - لا يمكن إدارة الانفجار الاندماجي إلا من خلال نظام متطور للتجميد. عندما تسوء الأمور ، ويحدث ذلك ، يكون من الصعب جدًا على المستخدم إعادة التحديث ، ويمكن لأشياء مثل انقطاع التيار الكهربائي في منتصف التحديث أن تؤدي إلى تعطل النظام بشكل لا رجعة فيه.

يغير نظام التشغيل المستند إلى OSTree كل ذلك.

أدرك أنه يمكنني استخدام podman مباشرة ، لكنني كنت مهتمًا بحل حاوية مع واجهة المستخدم الرسومية
دمج. عند البحث عن كيفية تحقيق ذلك باستخدام podman ، يكون استخدام toolbox هو
النهج الموصى به:

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

السؤال هو لماذا تريد استخدام Podman لتشغيل التطبيقات الرسومية؟ :)

بشكل عام ، يعد Podman (أو حاوية OCI) خيارًا سيئًا لتشغيل تطبيقات واجهة المستخدم الرسومية. هذا هو السبب الكامل لوجود Flatpak وعدم تنافس Toolbox معها.

ومع ذلك ، هناك تداخل ، بمعنى أن حاويات Toolbox لديها بعض التكامل مع سطح المكتب ، وهناك بعض الحالات التي تكون فيها القدرة على تشغيل تطبيق واجهة المستخدم الرسومية غير Flatpaked مفيدة للغاية على المدى القصير. قد يكون التطبيق الذي تريده لم يكن Flatpaked حتى الآن ، أو ربما يفتقد إصدار Flatpaked بعض الميزات. من المحتمل أنك تعمل في بعض المكتبات التي تستخدمها التطبيقات الرسومية ، وتريد تشغيل برنامج اختبار لمرة واحدة بسرعة لمعرفة ما إذا كانت مكتبتك تعمل بالشكل المتوقع.

يمكن لـ Toolbox ، في الواقع ، المساعدة في مثل هذه الحالات ، لكن هذا يختلف عن القول بأن الهدف الأساسي لـ Toolbox هو تجميع التطبيقات الرسومية في حاويات. الهدف الأساسي من Toolbox هو السماح لك بتنفيذ القرصنة على نظام تشغيل قائم على OSTree.

الآن ، إذا كنت تستخدم بيئة تطوير متكاملة للحاوية مثل GNOME Builder ، والتي يتم شحنها على أنها Flatpak ، وتقوم تلقائيًا بإعداد حاوية لإنشاء وتشغيل البرنامج الذي تعمل عليه ، فلن تحتاج إلى Toolbox على الإطلاق.

ومع ذلك ، لا يستخدم الجميع GNOME Builder ، كما أن IDEs الأكثر شيوعًا مثل Visual Studio Code ليست حاوية أصلية من هذا القبيل. ومن ثم ، Toolbox.

debarshiray شكرًا على الاستجابة المدروسة

لا يوفر Toolbox الأمان من سرقة الملفات الشخصية عند القيام بتطوير CLI مع أي تبعيات غير موثوق بها. نظرًا لتعقيد البرامج الحديثة مفتوحة المصدر ، لا بد أن تكون هناك بعض أجزاء شجرة التبعية التي لا ينبغي الوثوق بها.

أجد أن برنامج README الحالي مضلل: يبدو تشغيل "بدون امتياز بالكامل في حاوية" مثل الأمان ، ولكنه مجرد مسرح أمني - يمكن الوصول إلى جميع الملفات الشخصية في الحاوية. توضح أعلاه أن Toolbox لا تنوي تقديم أي مطالبات حول الأمان. أعتقد أنه سيكون من المفيد تضمين بيان في README لتوضيح أنه على الرغم من استخدام الحاويات ، فهذه أداة للراحة وليست للأمان.

debarshiray شكرًا على الاستجابة المدروسة
أعلاه لم يكن مخصصًا للتطبيقات الرسومية التي قد تغطيها Flatpak. أعطيت ال
مثال على القيام بتطوير Node.js. ظهرت مؤخرًا برامج ضارة حقيقية في Node.js
سلسلة تبعية يمكن أن تسرق من محفظة تشفير محلية. يمكن أن تتم سرقة مفاتيح SSH
بنفس السهولة. بينما يقول README أن المشروع يستهدف المطورين ، فإن
المشاركة مع الحاويات بشكل افتراضي لا تفعل شيئًا يؤمن المطورين من هذا النوع من الهجوم.

نعم ، في الوقت الحالي ، يحاول Toolbox فقط إعادة إنتاج البيئة التقليدية القائمة على الحزم ضمن نظام تشغيل قائم على الصور.

أجد أن برنامج README الحالي مضلل: التشغيل "غير مميز بالكامل في حاوية"
يبدو وكأنه أمان ، ولكنه مسرح أمني فقط - يمكن الوصول إلى جميع الملفات الشخصية بتنسيق
الحاوية. توضح أعلاه أن Toolbox لا تنوي تقديم أي مطالبات حول الأمان.
أعتقد أن هذا سيكون بيانًا مفيدًا لتضمينه في README لتوضيح أنه بالرغم من ذلك
استخدام الحاويات ، هذه أداة للراحة وليست للأمان.

الالتزام c047659c1d85ca982374da5c58ee7a24ba3847bd حيث تمت إضافة هذا الخط. أعتقد أن cgwalters قصدت القول إن لديك فقط حق الوصول إلى UID الخاص بك داخل حاوية صندوق الأدوات وأن الجذر الحقيقي (على سبيل المثال ، UID 0 على المضيف) ليس متورطًا أو متاحًا لك.

أنا أيضا لدي نفس المشكلة. لقد قمت بتثبيت Silverblue على أمل أن أتمكن من تشغيل برنامج قد لا أثق به تمامًا دون القلق من أنه يسرق مفاتيح SSH الخاصة بي وغيرها من المعلومات الحساسة.

كان إدراك أن صندوق الأدوات لا يسمح لي بالقيام بذلك خيبة أمل كبيرة وقادني إلى إعادة النظر في استخدام Silverblue كبداية. أنا شخصياً لا أهتم بتثبيت نظام التشغيل الرئيسي. يمكنني دائما إعادة تثبيت ذلك. المعلومات التي أريد حقًا الاحتفاظ بها منفصلة موجودة في دليل منزلي.

هل من الممكن أن تحدد بدقة أكبر أجزاء الدليل الرئيسية التي تتم مشاركتها؟ إذا كان بإمكان المرء أن يضيف إلى القائمة البيضاء فقط الدلائل التي يحتاجها صندوق الأدوات (ربما تلك المتعلقة بتكوين سطح المكتب ، إلخ) فإن هذا سيحل الكثير من المشكلات.

الآن ، أنا مدرك تمامًا للمشكلات المتعلقة بالأمان. منذ أن كنت أستخدم Qubes OS لعدة سنوات ، فإن مشكلة العزلة هي مشكلة صعبة. حتى إذا قمت بحماية الدليل الرئيسي ، فلن يكون ذلك كافيًا لأن البرنامج الذي يتم تشغيله داخل الحاوية يمكنه دائمًا الاستفادة من وسائل الاتصال الأخرى بين الحاويات ، مثل الحافظة. أنا على علم بهذا ، وأنا على استعداد لقبول بعض هذه المخاطر مقابل الراحة في شيء مثل صندوق الأدوات مقارنة بتثبيت Qubes الكامل.

تم نشر حل بديل هنا .

يستغل الحل البديل حقيقة أن toolbox يتم تنفيذه كبرنامج نصي bash يشير إلى متغير البيئة $HOME في جميع الحالات التي يجب فيها البحث عن مسار /home/user . لذلك ، من خلال تعيين متغير البيئة $HOME لاستدعاء معين إلى toolbox يؤدي إلى مشاركة دليل aa غير الدليل الرئيسي بالكامل المليء بالملفات الشخصية القيمة مع حاوية يحتمل أن تكون غير موثوق بها.

بناءً على ذلك ، يبدو أنه يمكنك مشاركة دليل فارغ يحتوي فقط على تكوين مربع الأدوات عن طريق تشغيل مربع الأدوات مع غلاف مثل هذا:

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

إذا تم تسمية هذا البرنامج النصي toolbox ووضعه في $ PATH قبل النظام toolbox ، فيبدو أنه سيعالج هذه المشكلة. هذا الحل لم يتم اختباره.

هذه الميزة تعمل الآن في tlbx fork: https://gitlab.com/uppercat/tlbx/issues/3

أنا أيضا لدي نفس المشكلة. لقد قمت بتثبيت Silverblue على أمل أن أتمكن من ذلك
قم بتشغيل برنامج قد لا أثق به تمامًا دون القلق من أنه يسرق SSH الخاص بي
مفاتيح وغيرها من المعلومات الحساسة.

أم ... هذا يبدو مضللًا. إذا كنت ترغب في تشغيل برنامج غير موثوق به كمستخدم ، فإن Flatpak يقلل بالفعل من مخاوفك بشأن فقدان المعلومات الحساسة. إذا كنت تريد بيئات تطوير معزولة ، فهذا شيء مختلف.

أيضًا ، لا شيء من هذا خاص بـ Silverblue بأي شكل من الأشكال. المشاكل موجودة منذ عقود ، والحلول ليست خاصة بـ Silverblue - فهي تعمل على أنظمة تشغيل تقليدية قائمة على الحزم أيضًا.

يستغل الحل البديل حقيقة أن toolbox يتم تنفيذه كبرنامج نصي باش
يشير إلى متغير البيئة $HOME في جميع الحالات التي يكون فيها المسار /home/user
يحتاج إلى البحث. لذلك من خلال تعيين متغير البيئة $HOME لمتغير معين
استدعاء toolbox يتسبب في وجود دليل aa بخلاف الدليل الرئيسي الكامل الخاص بك المليء بالقيمة
الملفات الشخصية التي ستتم مشاركتها مع حاوية يُحتمل أن تكون غير موثوق بها.

نعم ، هذا اختراق رائع. :)

ومع ذلك ، فإن الهدف الأساسي لمشروع Toolbox هو تمكين إعداد مجموعة متنوعة من بيئات التطوير على أنظمة تشغيل قائمة على الصور (خاصة المستندة إلى OSTree) بنفس القدر من الجهد اللازم على نظرائهم القائمة على الحزم. إن جعل بيئات التطوير هذه أكثر أمانًا هو بالتأكيد رغبة صحيحة ، لكنه ليس شيئًا مدرجًا في قائمة المهام الفورية ، لأن المشكلة ليست جديدة وهي موجودة منذ ذلك الحين إلى الأبد.

كما أن Silverblue لا يتعلق بالضرورة بالأمن. أراه على أنه تحسن في استقرار وقوة نظام التشغيل. ومع ذلك ، فإنه يشجع على استخدام Flatpaks ، ومن ثم فهو يعمل على تحسين الأمان بشكل غير مباشر.

لذلك ، هناك قيمة في ضمان تكافؤ الميزات مع توزيعات Linux القائمة على الحزم ، حتى لو احتفظت ببعض مشكلاتها الحالية. حل بعض المشكلات وإتاحة الحلول لقاعدة المستخدمين الحالية أفضل من حل أي شيء. :)

سأغلق هذه المشكلة حتى لا تخرج قائمة المشكلات المفتوحة عن نطاق السيطرة ، وتستمر في عكس العناصر الموجودة في قائمة المهام الحالية تقريبًا. ومع ذلك ، سيظل موجودًا للرجوع إليه في المستقبل.

أنا أوافق على أن قراءة README.md يجب أن تكون أسهل في القراءة ، بالرغم من ذلك.

حسنًا ، أنا لا أفهم هذه الحجة. فقط لأن المشكلة قديمة وظلت موجودة إلى الأبد ، فقط ألا تحلها ؟؟ هذه ليست وجهة نظر جيدة ، IMHO.
وكما تقول ، فإن Flatpak تفعل ذلك: تعمل خطوة بخطوة على تحسين الأمان وعزل التطبيقات. كما أنهم لم يقولوا "حسنًا ، لقد قمنا بشحن التطبيقات كحزم rpm إلى الأبد ، فلماذا يجب أن نحل هذه المشكلة؟" ، لقد قاموا بحلها للتو.

لا أرى أي سبب لعدم قيام toolbox بعزل دير المنزل أيضًا. لذلك أعتقد أن المناقشة يمكن أن تستمر في https://github.com/containers/toolbox/issues/348 على أي حال.

أعتقد أن المساهمين والمشرفين على صندوق الأدوات يأخذون هذا الموضوع باعتباره تقريعًا للفكرة والعمل الذي يتم وضعه في المشروع. أعتقد أنه يجب اعتبارها ميزة مطلوبة من قبل العديد من الأشخاص المتحمسين للفكرة. لا أحصل على مقاومة للعمل على ميزة تسمح لك بتحميل دليل عمل بخلاف $ HOME. إنها ميزة يمكنها تحسين الوظائف وحالة الاستخدام بشكل كبير والتي ستعمل أيضًا على تحسين التبني والاهتمام.

كنت أنا من اقترح تغيير متغير $ HOME في رقم 348. إنه حل متطفل لأنه يسبب مشاكل عندما تريد العمل مع حاويتين متعددتين بدلائل $ HOME مختلفة. خوفي هو أن هذا لن ينجح حتى عند إعادة كتابة صندوق الأدوات مع go.

يطلب الكثير من الأشخاص هذه الميزة وقد أصبحت عائقًا أمام دخول العديد من الأشخاص إلى تبني صناديق الأدوات و rpm-ostree و silverblue. حتى لو لم يكن الأمر يتعلق بالأمان ، فهي ميزة ستفتح الكثير من الاحتمالات للعمل مع صناديق الأدوات.

أنا على استعداد للمساعدة في هذه القضية إذا كان بإمكاني وأعتقد أن الآخرين سيكونون على استعداد أيضًا. آمل ألا تصبح هذه الميزة نقطة خلاف وأن يتم استبعادها من إصدارات صندوق الأدوات المستقبلية. إنه في رأيي الشيء الوحيد المفقود حاليًا فيه. سيكون مثل الحصول على dnf في سباق الماراثون بسبب الانسحاب من آخر 10 أمتار. (يقصد التورية :) )

لقد كانت صفقة فاصلة بالنسبة لي. لقد تخليت عن صندوق الأدوات و Silverblue بعد ذلك
إيجاد هذا الخلل.

فقط لأن المشكلة قديمة وظلت موجودة إلى الأبد ،
فقط لا تحلها ؟؟ هذه ليست وجهة نظر جيدة ، IMHO.

عدم وجود شيء ما في قائمة المهام الفورية ليس هو نفس الشيء مثل عدم حله . هناك شيء مثل الأولوية .

وكما تقول ، فإن flatpak تفعل ذلك: تعمل خطوة بخطوة على تحسين الأمان و
يعزل التطبيقات. كما أنهم لم يقولوا "حسنًا ، لقد قمنا بشحن التطبيقات باسم
حزم rpm للأبد ، لماذا يجب علينا حل هذه المشكلة؟ "، لقد فعلوا ذلك للتو
حلها.

أنا أحب استخدامك للكلمة هم .

حسنًا ، رائع ، إذا فسرت ذلك بشكل صحيح ، فقد تظل هذه فكرة للمستقبل ، ولكن ليس فقط في "قائمة المهام الفورية"؟ (على الرغم من أنني أعتقد أنه من السهل التنفيذ ، خاصة إذا كان بإمكانك فقط اختيار بعض التصحيحات من شوكة ) *

إذا كان الأمر كذلك ، فربما أبقِ هذه المشكلة مفتوحة وقم بوضع علامة عليها كـ "مساعدة مطلوبة" - على الرغم من أنك لا تحتاج حقًا إلى المساعدة ، لا تدع ... ما الذي يمنعك من تنفيذ هذا؟ أعتقد أنك تحتاج فقط إلى القول إنك تقبل العلاقات العامة حول هذا الموضوع وسيتم تنفيذه.
لا أرى شيئًا يمنعك من ذلك - ولا يزال بإمكانك تحقيق تكافؤ الميزات أو ما شابه ، أيا كان ... إنها حقًا مجرد ميزة ثانوية. : التفكير:

* نعم ، أرى وأعلم أنه تمت إعادة كتابته في Go now ، لكن ربما لا يزال هذا مفيدًا أو نحو ذلك - dunno. على الأقل يوضح أنه سهل التنفيذ.

اختطاف هذه المشكلة قليلاً هنا في حالة رغبة أي من المشاركين في تسجيل المغادرة وتقديم ملاحظات حول النموذج الأولي الخاص بي على https://gitlab.com/bkhl/etui

يُقصد به أن يكون بديلاً لـ Toolbox عندما تريد حاوية تطوير أكثر احتواءً بشكل صارم.

bkhl شكرا! مرجعية.