GitHub Actions / الهوية والتنسيق والحوكمة / الدرس 16
الأحداث المميزة والمصدر غير الموثوق
افصل أتمتة البيانات عن تنفيذ شيفرة ونواتج المساهم.
في هذه الصفحة
أهداف الدرس
- شرح فرق الثقة بين حدثي الطلب.
- مراجعة نواتج workflow_run ومسارات التنفيذ غير المباشر.
يغير الحدث سياق الثقة
يحتوي طلب نسخة متفرعة شيفرة يتحكم بها طرف خارج كتّاب المستودع الموثوقين. توثق GitHub قيود الرمز والأسرار لمسار التحقق قليل الثقة. يستخدم pull_request_target سياق سير من المستودع الأساسي وقد يحمل سلطة أعلى وفق السياسة والأذونات الفعلية. يخدم مهام بيانات وصفية، ولا يختصر تشغيل شيفرة متفرعة مع الأسرار. راجع الحماية والإعداد الحاليين لأن الافتراضات والفرض يتطوران. لا تثبت مقالة قديمة حد الأمان الحالي، كما أن الحاجة إلى تعليق أو وسم لا تبرر منح عملية بناء كامل تلك السلطة.
السحب أول وصلة فقط
يحدث الخلل الحاسم حين يستهلك تنفيذ مميز شيفرة مساهم. قد يتم ذلك باختبار صريح أو خطاف تثبيت أو إعداد بناء أو إضافة أو نص مساعد. وليس checkout طريق الاكتساب الوحيد؛ تستطيع نواتج منزلة ومستودعات أخرى ومراجع مجلوبة يدوياً توفير التأثير نفسه. ينبغي لمهمة بيانات Parcel المميزة فحص بيانات مقبولة دون تنفيذ الاقتراح. لا تفترض أن اسماً بريئاً مثل build أو install يشغّل فقط شيفرة كتبها صاحب السير. راجع من يتحكم بالملفات التي يقرؤها الأمر وبالاعتمادات التي يستدعيها لاحقاً.
افصل دوري التحقق والبيانات
يحرم التصور التالي تحقق الاقتراح من سلطة الإصدار ويبقي معالجة البيانات المميزة على تنفيذ موثوق. هو رسم مراجعة لا إعداد أحداث فعلي ولا يثبت نمط سحب خطراً. يجب على الترقية اللاحقة التحقق من المرشح وعلاقته بالمصدر دون تنفيذ نصوص مرفوعة اعتباطياً. يفيد فصل الملفات والسير فقط إذا فُرض حد البيانات والسلطة الناتج فعلاً. لا يزيل تغيير اسم المهمة هوية مضيف مشتركة أو تأثير ذاكرة تنفيذية. لذلك اختبر الحدود الفعلية ولا تستنتج العزل من عدد ملفات YAML.
untrusted proposal -> restricted validation -> reports treated as data
trusted metadata implementation -> narrowly authorized metadata operation
verified candidate -> separate reviewed promotion decisionتعبّر المسارات عن حدود ثقة مقصودة. راجع السياسة والرمز والعزل والاعتماد والمستهلك. لا تنفذ شيفرة اقتراح ولا عملية API بيانات.
لا يجعل التشغيل السابق رفوعه موثوقة
يمكن لـ workflow_run بدء أتمتة لاحقة بسياق سلطة مختلف. نتيجة السابق دليل عنه لا موافقة شاملة على كل بايت مرفوع. تحقق من المنشأ والمستودع والحدث والمراجعة واختيار الناتج وعلاقته بالقرار. حلل التقارير كبيانات مقيدة ولا تنفذ برامج منزلة. قد يتحكم مساهم في النص أو الاسم حتى مع نجاح الاختبارات. راعِ مسارات استخراج الأرشيف والحقن التطبيقي في المستهلك المميز أيضاً. ينبغي للمرحلة اللاحقة أن تعيد إثبات ما تحتاجه من حقائق مرجعية بدلاً من قبول وصف المنتج لنفسه.
اشترط الثقة إلى جانب النجاح
يمثل الشرط المحلي الكامل ثلاث حقائق مطلوبة: منشأ موثوق واختيار ناتج متوقع وأدلة مطلوبة ناجحة. يرفض المصدر غير الموثوق رغم نجاحه. ليس مدقق حدث GitHub ولا سياسة نواتج شاملة. يجب أن تأتي حقائق التحكم من أدلة منصة موثقة لا من حقل داخل تقرير. يوضح النموذج ثابتاً واحداً: لا يعلن الناتج ثقته بنفسه، ولا يفوض نجاح تنفيذ قليل الثقة عملية أعلى سلطة تلقائياً. تبقى المصادقة والربط وتحقق التنسيق وحدود المسموح مسؤوليات فعلية خارج هذه القيم المنطقية التعليمية.
def eligible(trusted_origin, expected_artifact, required_checks):
return trusted_origin and expected_artifact and required_checks
print(eligible(False, True, True))
print(eligible(True, False, True))
print(eligible(True, True, True))False
False
Trueالقيم ملاحظات افتراضية معلنة. لا يقرأ البرنامج حدثاً أو رمزاً أو أرشيفاً أو مستودعاً ولا يثبت ثقة فعلية.
الأخطاء الشائعة وإصلاحها
يُختار الحدث المميز لإتاحة سر للاختبار.
- لماذا يحدث؟
- عبرت الراحة إلى تنفيذ مميز غير موثوق.
- كيف تصلحه؟
- أبق تحقق المتفرع مقيداً وصمم العملية الموثوقة منفصلة.
- كيف تتجنب تكراره؟
- راجع التأثير التنفيذي قبل السلطة.
ينفذ التالي نصاً من ناتج مرفوع.
- لماذا يحدث؟
- عومل النجاح السابق كثقة في بايتات مساهم.
- كيف تصلحه؟
- استهلك بيانات مقيدة متحققة وتجنب تنفيذها.
- كيف تتجنب تكراره؟
- راجع المنشأ والموضوع وكل مستهلك.
تُعد حماية السحب شاملة لكل الطرق.
- لماذا يحدث؟
- تصل الشيفرة عبر جلب واعتماد وتنزيل أيضاً.
- كيف تصلحه؟
- تتبع كل المدخلات التنفيذية لا إعداداً واحداً.
- كيف تتجنب تكراره؟
- عامل ضوابط المنصة كطبقات ضمن مراجعة كاملة.
اختبر فهمك
1. يعالج سير موثوق عنوان الطلب ويضيف وسماً. هل يحتاج بناءه؟
اعرض الحل المشروح
لا. أبق التنفيذ موثوقاً والعنوان بيانات متحققاً منها لعملية API ضيقة. يضيف البناء تأثيراً تنفيذياً غير مرتبط بالقرار. راجع حقن المدخل وفق مستهلكه الفعلي.
2. يقول التقرير trusted=true ونجحت الاختبارات. هل يعتمد التالي ذلك؟
اعرض الحل المشروح
لا. يتحكم المنتج بالادعاء. أثبت المنشأ والمراجعة من المنصة ووثق البنية وطبق سياسة المستهلك. افصل ملاحظات التقرير عن سلطته المزعومة.
أهم ما تعلمته
- تتبع السلطة الحدث والتنفيذ الفعليين.
- تتبع كل طريق لتحول البايتات إلى شيفرة.