من الجيد أن هذه المشكلة “تم حلها” لهذا المستودع. لكن المشكلة الحقيقية لا تزال قائمة. كيف تقوم بالتوقيع، وما هو المصدر للمفتاح للتحقق من التوقيع به.
لذا فإن محاولتي الأولى لحل هذه المشكلة ستكون الاستفادة من آلية التوقيع المدمجة في git. سيحتاج Discourse بعد ذلك إلى تتبع المُوقِّع لمكون إضافي مُثبَّت. إذا تغير ذلك، فيجب أن يحذر المسؤول.
هذا لديه بالتأكيد الكثير من الثغرات.
من أين تحصل على مفاتيح المُوقِّع؟ البيانات الوصفية في plugin.rb و about.json. خوادم المفاتيح لطيفة… ولكنها معقدة للغاية. أو… يعمل meta.discourse.org كخادم مفاتيح، لذا يجب على المؤلفين تسجيل مفاتيحهم العامة.
التحقق من أحدث التزام فقط؟ ربما يكون كافياً، لا يمكنك فعل الكثير بشأن المفاتيح المسروقة.
ولكن إذا سُرق مفتاح، كيف تتحقق من الإلغاء؟ إذا كان meta يخدم المفتاح، يمكن حل هذه المشكلة.
هذا رائع لواجهة المستخدم الإدارية، ولكن ماذا عن تثبيتات المكونات الإضافية في حاوية docker؟ احفظ مفاتيح التوقيع المقبولة سابقًا في مشاركة، وأضف خطوة تحقق إلى إعادة البناء. ربما فحص ما قبل البناء لمنع تعطيل النظام ثم رفض الاستنساخ؛ ثم فحص ما بعد الاستنساخ في حال عبث شخص ما بالمستودع في هذه الأثناء؟
ماذا عن المستودعات القديمة غير الموقعة؟ تحذير كبير بأن محتواها لا يمكن التحقق منه. + مطالبة بنعم/لا/إلغاء.
لديه مسؤولية. يجب على مالك الخادم التأكد من أن بعض الخوادم تقوم بتحميل الكود المطلوب. سواء كان ذلك بتوجيه اللوم إلى GitHub، أو إلى أعلى المنبع إلى نطاق المستوى الأعلى الخاص بهم (على سبيل المثال، .com)، أو إلى أسفل المنبع
ولكن اجعل عملي، كمسؤول، أسهل. أنا، كمطور إضافات، أريد أن أجعل عملك أسهل.
حاليًا، يعتمد الترقية بشكل مطلق على الثقة في URI المصدر. هذا يقلقني، حيث ثبت أن المصدر (github) غير موثوق به، خاصة في خطوات معينة عند إعادة بناء الحاوية. قم بتحذيري، كمسؤول، عندما يكون هناك تغيير في علاقات الثقة.
لقد قمت أنا، كمسؤول، بفحص كل إضافة أو مكون سمة قبل إضافته. بعد ذلك، يوفر لي Discourse القليل من التوجيه أو لا يوجهني على الإطلاق في الفحص. اليوم احتجت إلى إعادة بناء الحاوية الخاصة بي، والتي ستعيد استنساخ جميع الإضافات. أنا خارج السيطرة تقريبًا، إلا إذا قمت بتغيير متقدم في الإعداد لتثبيت إصدار معين.
قد ينجح هذا معي كمطور برامج مرتاح في اللحظة التي أحتاج فيها إلى إجراء بعض الصيانة. ولكن هذه قيود كبيرة. إلى جانب جعل Discourse منصة رائعة للنقاش. نحتاج أيضًا إلى جعلها منصة آمنة تقنيًا للنقاش. يمكن للإضافات المخترقة أن تسبب أضرارًا جسيمة. يمكن لمكونات السمات المخترقة أن تسبب أضرارًا كبيرة.
أعتقد أن هذا منطقي للغاية. لدينا SRI لجافاسكريبت، و MS Authenticode لنظام ويندوز.
كانت هناك الكثير من هجمات سلسلة التوريد على سبيل المثال NPM و RubyGems.
الشيء الوحيد الذي يقلقني هو أنه سيكون هناك حاجز أمام الأشخاص لقبول مكون الإضافات أو السمات الخاصة بهم، مثل كيف يمنع Microsoft Smartscreen المستخدمين من تشغيل البرامج الأقل شهرة من مطورين فرديين.