الجهة القادرة على تجاوز ruleset في GitHub ليست حدث تجاوز

الخلاصة

• يعرّف GitHub bypass_actors على أنها جهات يمكنها تجاوز ruleset؛ فهي إعداد للقدرة وليست سجل حدث.
• تمثل rule suite سطح دليل مختلفاً: تربط أمثلة GitHub التقييم بجهة وref وSHA قبل وبعد ونتيجة ونتائج القواعد المفردة.
• يحتاج الاستثناء المهم إلى حفظ نسخة السياسة والقدرة والانتقال المقيّم والموافقة المنفصلة وملاحظة التسليم اللاحقة كلّاً في موضعه.

تبدو عبارة «يمكن لهذه الجهة تجاوز القاعدة» كأنها قصة مكتملة. لكنها في الواقع تصف قدرة فحسب. يتيح GitHub تعيين جهات مخوّلة لتجاوز قواعد ruleset. وقد يكون ذلك مناسباً لاستمرارية التشغيل أو الاستجابة العاجلة أو توزيع المسؤوليات بوضوح. لكن ظهور مستخدم أو فريق أو تطبيق أو دور أو مفتاح في bypass_actors لا يثبت حدوث push أو pull request أو تقييم ref محدد أو استعمال التجاوز أو موافقة عليه.

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

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

أما الدليل على انتقال معين فيأتي من rule suite، وهو سجل مختلف. يصفه GitHub بأنه مجموعة تقييمات للقواعد ويمكن تصفيته وفق ref والفترة والجهة والنتيجة وحالة التقييم. وتضم الأمثلة الجهة والمستودع وref وSHA السابق واللاحق والوقت والنتيجة ونتيجة التقييم وتقييمات القواعد المنفردة. لذلك قد تدعم suite تحمل result: bypass حكماً محدوداً: المنصة تعاملت مع هذا الانتقال المحدد كتجاوز. لكنها لا تثبت وحدها أن موافقة بشرية لازمة قد صدرت، أو أن سبب الاستثناء قُبل، أو أن التغيير دُمج، أو أن شيئاً وصل إلى الإنتاج.

يزيد تراكب الحمايات من أهمية الفصل. يوضح GitHub أن rulesets وقواعد حماية الفروع قد تعمل معاً وأن جميع القواعد المنطبقة تنفذ. وعليه فإن النظر إلى ruleset منفردة قد لا يصف السياسة الكاملة المطبقة على ref. وبالمقابل قد تعرض suite نتائج مصادر قواعد متعددة من دون أن تصبح ملف مراجعة أو قرار حوكمة كاملاً. السؤال المنضبط هو: أي نسخة سياسة انطبقت على أي ref وانتقال SHA، وماذا قيّمت المنصة، وأي سجل آخر يثبت الموافقة أو الأثر الذي يراد ادعاؤه؟

يقترح Daniel Kade إيصال استثناء محدوداً: معرّف المستودع، ref الدقيقة، SHA قبل وبعد، وقت الرصد، مصدر ruleset ونسختها أو لقطة سياسة محفوظة بأمان، الجهة ووضع التجاوز، نتيجة suite ونتيجة التقييم، وتقييمات القواعد اللازمة للشرح. إن تطلب الأمر موافقة، تحفظ بمعرّفها وصاحب القرار ونطاقها ووقتها في سجل مستقل. ويبقى الدمج أو الوسم أو الإصدار أو النشر ملاحظة مستقلة لاحقة. يمكن حماية التفاصيل الحساسة من دون صهر القدرة والفعل والموافقة والنتيجة في سطر واحد.

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

المصادر

1. GitHub Docs — حول rulesets
2. GitHub Docs — نقاط REST للقواعد
3. GitHub Docs — نقاط REST لـ rule suites