Skip to the guide
All guides

التحقق من الإصدارات

كيف تتحقق بالمجموع الاختباري وبشهادة مصدر البناء من أن أرشيف الإصدار هو الملف الذي بناه سير عمل الإصدار، وما علاقة ذلك بالتثبيت عبر Composer.

app RTLY-Kit 0.2.0checked reading 3 minutes

On this page

ما الذي يتضمنه الإصدار

يؤدي دفع وسم إصدار مثل v0.2.0 إلى تشغيل سير عمل الإصدار في مستودع GitHub. وقبل أن يبني أي شيء يفحص أربعة أمور: أن الوسم إصدار صالح، وأن أحدث قسم في CHANGELOG.md يحمل الإصدار نفسه، وأن الإيداع الموسوم ضمن الفرع main، وأن تشغيل CI لذلك الإيداع ناجح. وإذا فشل أي فحص فلا يُنشر شيء.

ثم يبني الأرشيفين بالأمر git archive، فتُستبعد الملفات الموسومة بـ export-ignore (الاختبارات ومصادر الدليل وملفات الأدوات وCI وcomposer.lock). ويحتوي إصدار GitHub لذلك الوسم على الملفات الآتية:

  • rtly-kit-X.Y.Z.tar.gz و rtly-kit-X.Y.Z.zip ، وهما الإيداع نفسه بصيغتين.
  • SHA256SUMS ، وفيه المجموع الاختباري SHA-256 للأرشيفين.
  • شهادة موقَّعة لمصدر البناء لكلا الأرشيفين، يحتفظ بها GitHub. وهي ليست ملفًا في صفحة الإصدار.

ملاحظة. هذه الملفات موجودة فقط في الإصدارات التي نشرها سير العمل هذا. وقد لا تحتوي إصدارات أقدم على أي منها. استبدل X.Y.Z بالإصدار الذي نزّلته.

فحص المجموع الاختباري

نزّل الأرشيف وSHA256SUMS في مجلد واحد ثم شغّل:

Bash
sha256sum --check SHA256SUMS

يجب أن ينتهي كل سطر بـ OK. وإذا نزّلت .tar.gz وحده فسيعدّ الأمر غياب .zip خطأً؛ فاستخدم sha256sum --check --ignore-missing SHA256SUMS. وفي macOS استخدم shasum -a 256 -c SHA256SUMS.

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

فحص مصدر البناء

مع تثبيت GitHub CLI (opens in a new tab):

Bash
gh attestation verify rtly-kit-X.Y.Z.tar.gz --repo ehsanenaloo/RTLY-Kit

يبحث الأمر عن الشهادة التي وقّعتها GitHub Actions لهذا الملف بعينه ويفحصها. وتعني رسالة النجاح أن الأرشيف أنتجه تشغيل لسير عمل في المستودع ehsanenaloo/RTLY-Kit، وأن الملف لم يتغير منذ ذلك الحين. شغّل الأمر نفسه على ملف .zip إن كنت تستخدمه.

التثبيت عبر Packagist وComposer

تعلم Packagist بالوسم الجديد عبر webhook خاص بها، فيثبّت composer require tsi/rtly-kit شيفرة الوسم نفسه. ولا يعمل سير عمل الإصدار إلا لإيداع موسوم يقع ضمن main.

الأرشيف الذي ينزّله Composer تولّده GitHub للوسم؛ وليس هو الملف المشهود له أعلاه. ولمعرفة أي إيداع حصلت عليه، انظر في composer.lock تحت tsi/rtly-kit: القيمة source.reference هي تجزئة الإيداع. وقارنها بالوسم:

Bash
git ls-remote https://github.com/ehsanenaloo/RTLY-Kit refs/tags/vX.Y.Z

وفي وسم يشير إلى إيداع، تكون التجزئة المطبوعة هي نفسها الموجودة في ملف القفل لديك. (الوسم المشروح يطبع سطرًا ثانيًا ينتهي بـ ^{}؛ وهذا السطر هو الإيداع.)

ما لا يثبته هذا

  • لا يراجع الشيفرة. فهو يبيّن من أين جاء الأرشيف، لا أن الشيفرة خالية من الأخطاء. وللثغرات المعروفة في بيانات المرجع راجع الدقة والبيانات .
  • وسوم git غير موقَّعة. وتعتمد الفحوص أعلاه على المستودع وسير عمله وخدمة الشهادات في GitHub.
  • لا توجد قائمة مواد برمجية (SBOM) منفصلة. فالحزمة بلا اعتمادات إلزامية (راجع التثبيت ).

للإبلاغ عن مشكلة أمنية في إصدار، راجع الملف SECURITY.md في المستودع.