Git وعدم الرفض، إعادة النظر
Joe Schaeferهذا المقال يتعلق حقا إلى DVCS بشكل عام، وليس فقط git في حد ذاته. لكننا سنركز الاهتمام على git لأنه لا يزال DVCS الأكثر شعبية حول اليوم.
عدم الرفض وهو مفهوم مهم في الدوائر الأمنية. ما يصل إليه هو إرضاء مؤسسة’الحاجة إلى الحصول على سجلات النشاط التي “لا يمكن الابتعاد عن الواقع”.
باستخدام أداة تحكم مركزية تقليدية في الإصدار، تتوفر هذه السجلات بسهولة من سجل التثبيت. يمر كل التزام بالنظام بآلية تفويض للتأكد من أن الشخص الذي قام بالتغيير مصرح له بتحميله. هذه السجلات حيوية للمؤسسة لضمان الاحتفاظ بسجلات دقيقة تشير إلى المسؤول عن تحميل كل سطر من التعليمات البرمجية إلى البرنامج المعني.
مع git، أو التحكم في الإصدار الموزع بشكل عام، هناك تمييز واضح بين “يلتزم” التاريخ و “رفع” تاريخ — التي سأشير إليها على النحو التالي: “يدفع السجلات”. لا يتم التصديق على الالتزامات في git، لأنها تحدث محليًا، مع إضافة بيانات تعريف محلية لم يتم التحقق منها إلى التاريخ. خطوة التحميل، aka يسحب إنها خطوة منفصلة، وهنا يتم تشغيل سجلات الدفع.
مع مؤسسة برامج أباتشي‘نشر git، خبزنا في النظام طريقة لتسجيل تلك السجلات الدفع بطريقة تجلب مستويات موازية من السجلات غير القابلة للرفض التي تتمتع بها المنظمة مع خدمة التخريب طويلة الأمد. ولكي يعمل النظام بشكل صحيح، من الضروري أن يقوم الملتزمون بدفع تغييراتهم مباشرةً إلى ASF’جيت ريبو
ما أهمية هذا؟ حسنا بالنسبة للمبتدئين اسمحوا لي أن أتناول فكرة خاطئة شائعة حول الحاجة إلى اتفاقيات ترخيص المساهمين (ICLAs) لملتزمي أباتشي. كثير من الناس لا’لا يبدو أن نفهم أنه بقدر ما مفترس’أعمال التأليف الفردية، لا يوجد فرق بين اللغة المعمول بها في اتفاقية مستوى الخدمة و رخصة أباتشي 2.0. ويكمن التمييز في حقيقة أن المنظمة تحتاج إلى اتفاق تعاقدي بين الملتزمين وASF للتعامل مع العملية المناسبة للتعامل مع مساهمات الطرف الثالث. هذه الأشكال من المساهمات هي التي تستلزم من ICLA، وليس بعض الحزام والمعلقين الغريبين للتعاقد مع الآخرين.
ما توفره سجلات الدفع بعد ذلك هو طريقة لتعقب، إلى كل سطر من التعليمات البرمجية في إصدار، المثبت الفردي المسؤول عن دفع تلك التعليمات البرمجية إلى ASF’مستودع git. هذا أمر بالغ الأهمية في تحديد مصدر مساهمة طرف ثالث مع git، لأنه من الممكن للأسف لمثل هذا المساهم في “غادر” من مساهمته في مشروع git بسبب الطبيعة الموزعة لسجلات تثبيت DVCS. ثم يصبح الطرف المسؤول، وفقًا لـ ICLA، هو المسؤول الذي دفع الرمز.
وتدور جميع استراتيجيات التخفيف المبكر والسليم حول إزالة المساهمة المهجورة، ولكن الضرر الذي لحق بالمشروع ربما يكون قد حدث بالفعل. وبدون سجلات الدفع، نحن’د حرفيا ليس لديهم عملية موثوقة لتحديد كيفية دخول هذا الرمز في الواقع إلى مستودعنا، بخلاف الصيد بالشباك من خلال سجلات بديلة في متعقبات المشكلات أو الاتصالات المدرجة في القائمة. إن الاعتماد على سجلات التزام الدمج وحدها لتحديد المصدر ليس مرضيًا للغاية من وجهة نظر أمنية، لأنه يتطلب التزامًا صارمًا بنوع معين من سير العمل، والذي لا نقوم به.’لا تريد أن تملي.
بدون مثل هذه الأشياء نحن’(د) ضرورة تكليف كل مساهم بتوقيع PGP على الأقل’يلتزم، وهو أمر مرهق للعديد من المشاريع. توفر سجلات الدفع عملية شفافة لا تؤثر على المشروع’سير العمل، بخلاف التأكد من ASF’s git repo هو المستودع الرئيسي الحقيقي.
تحديث 2025
لدى Git دعم أصلي لـ SSH-SK-ED25519@openssh.com مفاتيح التوقيع، والتي هي مناسبة كبيرة للتبني التنظيمي للبنية التحتية توقيع 2FA الالتزام / العلامة التي تتضمن USB-C YubiKeys لاستخدام الكمبيوتر المحمول / محطة العمل.
لم يعد الانتفاخ والتعقيد اللازمين للبنية التحتية الكاملة لـ PGP مناسبًا لحل قضايا عدم الإنكار التي تمت مناقشتها أعلاه، عبر المؤسسة أو على مستوى كل مشروع. ويسهل تكامل GitHub الجميل هذا الجهد بالكامل.