لنفترض أن تطبيق سطح مكتب متاح من صفحة إصداره ومن مرآة تنزيل. تتطابق أسماء الملفات وأرقام الإصدارات، لكن المستخدم يحتاج إلى إجابات: هل هو الملف نفسه، ومن نشره، وهل نتج من الشيفرة وعملية البناء المتوقعتين، وهل يناسب تشغيله على هذا الجهاز؟
تحتاج هذه الأسئلة إلى أدلة مختلفة. تسمية كل طرق التحقق «شهادة أمان» تولد توقعات لا تستطيع تلبيتها، وقد تجعل المطور يغفل ثغرات في عملية الإصدار.
المجاميع الاختبارية تجيب عن تطابق الملفات
حساب تجزئة بعد التنزيل ومقارنتها بالقيمة المتوقعة قد يثبت تطابق محتوى الملف. والشرط المهم أن تأتي القيمة المتوقعة من قناة موثوقة. إذا جاء الملف ومجموعه الاختباري من الصفحة غير المتحققة نفسها، فإن تطابقهما لا يثبت هوية الناشر.
وبالعكس، اختلاف التجزئة يعني اختلاف الملفات، لكنه لا يثبت وحده نية خبيثة. قد يكون السبب بناءً مختلفًا أو إعادة تغليف أو تنزيلًا خاطئًا. توقّف عن اعتبار الملف إصدارًا متحققًا منه، وأعد تأكيد مصدره ومنصته المستهدفة وسجل المجموع الاختباري الموافق.
ينبغي للناشر الحفاظ معًا على أسماء ملفات واضحة ومعلومات الإصدارات وقوائم المجاميع. لا ينبغي أن يضطر المستخدم إلى نسخ تجزئة من مقالة قديمة ومقارنتها بمثبّت لمنصة أو بناء آخر.
التواقيع تتطلب فحص الهوية المتوقعة
يربط التوقيع الرقمي الموقّع بالبيانات الموقّعة، لكن التحقق يجب أن يحدد أيضًا ما إذا كانت الهوية هي المتوقعة. تشترط وثائق Sigstore فحص التواقيع مع شروط الهوية والجهة المصدرة ذات الصلة، موضحة هذا الفرق. وثائق التحقق في Sigstore
عند رؤية «توقيع صالح»، يجب أن يعرف المستخدم أي ناشر أو سير عمل يمثله. ينبغي للمطور تحديد الهويات المسموح لها بتوقيع الإصدارات الرسمية. لا يجوز أن يمنح كل توقيع يجتاز فحصًا رياضيًا صفة الإصدار الرسمي تلقائيًا.
وعندما يغيّر الناشر الشهادات أو أساليب التوقيع، عليه تقديم تفسير يستطيع المستخدم التحقق منه. مطالبة المستخدم بالثقة الفورية بشهادة غير مألوفة ليست عملية تحديث مكتملة.
منشأ البناء يربط الحزمة بعملية إنتاجها
تستطيع شهادات مخرجات GitHub تسجيل منشأ البناء والمساعدة في التحقق من ارتباط المخرج بمعلومات المستودع وسير العمل. إنها أدلة على كيفية إنتاج الملف، لكن التحقق يظل بحاجة إلى فحص المخرج الفعلي والهوية المتوقعة. وثائق شهادات مخرجات GitHub
تميّز مستويات بناء SLSA أيضًا بين وجود سجلات المنشأ، والمنشأ الموقّع الذي تولده منصة مستضافة، وحماية أشد لمنصة البناء. عند ذكر مستوى، وضّح نطاقه وأدلته بدل اعتبار الرقم تقييمًا لكل مخاطر البرمجيات. مستويات بناء SLSA
| الدليل | ما يساعد أساسًا على إثباته | ما لا يثبته وحده |
|---|---|---|
| المجموع الاختباري | هل تم الحصول على محتوى الملف المتوقع؟ | هوية الناشر أو سلامة سلوك البرنامج |
| التوقيع الرقمي | من وقّع أي بيانات؟ | هل يلبي الموقّع متطلبات الثقة لديك؟ |
| منشأ البناء | أي عملية بناء أنتجت المخرج؟ | خلو جميع الشيفرات والاعتماديات من المشكلات |
| بناء قابل لإعادة الإنتاج | هل يمكن إنتاج المخرج نفسه في ظروف محددة؟ | خلو البرنامج من الثغرات أو السلوك غير الملائم |
يمكن لهذه الأدلة أن تكمل بعضها. ينبغي للمطور شرح ما يقدمه والفحوص التي يجب إتمامها بصورة مستقلة.
إعادة إنتاج البناء تتطلب مدخلات وبيئات صريحة
يعرّف مشروع Reproducible Builds البناء القابل لإعادة الإنتاج بأنه إنتاج المخرجات المحددة متطابقة بتًا ببت من الشيفرة المصدرية وبيئة البناء وتعليماته نفسها. وهذا هدف تحقق أدق من «يمكن ترجمته على جهازي». تعريف البناء القابل لإعادة الإنتاج
نوصي بحفظ سلسلة الأدوات ومعلومات قفل الاعتماديات ومعاملات البناء وعلاقتها بمخرجات الإصدار. إن لم تتحقق إعادة الإنتاج، فسجّل بدقة مدى نجاح البناء مجددًا بدل تجاهل الاختلافات وإعلان النجاح.
يحتاج نطاق المستودع العام إلى شرح أيضًا. قد يحتوي الشيفرة الأساسية، أو قد يتكون أساسًا من أدوات بناء وإعدادات وحزم تطبيق مولدة من المصدر الأعلى. يحتاج المستخدم إلى معرفة الأجزاء التي يستطيع فعلًا مراجعتها وإعادة بنائها لتقييم أدلة المنشأ بعقلانية.
تسلسل عملي لفحص التنزيل
- أكّد مستودع الإصدار عبر المدخل الرسمي للمشروع، بدل الاعتماد على إعلانات البحث أو الروابط المتداولة وحدها.
- اقرأ ملاحظات الإصدار وتحقق من نظام التشغيل ومعمارية المعالج وقناة الإصدار.
- قارن الملف بمجموعه الاختباري المقابل. وحيث تتوافر تواقيع أو معلومات منشأ، افحص الهوية المتوقعة والنطاق أيضًا.
- راجع حالة الصيانة والقيود المعروفة دون افتراض أن وسم «الأحدث» يعني ملاءمة الاستخدام الإنتاجي.
- عند تعارض المعلومات، احتفظ بالإصدار واسم الملف واطلب التوضيح عبر قنوات دعم المشروع.
لا تتطلب هذه العملية أن يصبح كل مستخدم مهندس بناء. يستطيع المنتج تنظيم الأدلة المعقدة في صفحة إصدار واضحة تشرح مصدر الملفات ولمن تناسب وكيفية فحصها وأين تُطرح أسئلة الاختلافات.
بالنسبة للمطور، صيانة سلسلة المعلومات مع الزمن أثمن من شارة «تم التحقق» لمرة واحدة. يجب أن يظل المستخدم قادرًا على العثور على التفسير المناسب عند سحب إصدار قديم أو تغيير طريقة التوقيع أو إخفاق التحديث.
يميّز وصف مستودع AlphaBiz العام بين أدوات البناء وحزم التطبيق المولدة من المصدر الأعلى. وعند مناقشة تطبيقات سطح مكتب كهذه، ينبغي وصف نطاق الفحص الفعلي بدل الخلط بين مستودع عام وشيفرة كاملة وإصدارات قابلة لإعادة الإنتاج. نظرة عامة على مشروع AlphaBiz
يستطيع المطور البدء بإكمال جرد أدلة الإصدار، والمستخدم بفحص تنزيل واحد لتطبيق يستخدمه كثيرًا. شارك معلومات التحقق التي تود أن تقدمها صفحات الإصدار في نقاشات AlphaBiz.