الخلاصة

  • ينزّل دليل LACNIC المنشور في 10 أغسطس fort-1.7.0.experimental.tar.gz على Ubuntu Server 26.04، ثم يفكّه ويبنيه وينفذ sudo make install من دون فحص SHA-256 أو التوقيع المنفصل.
  • كانت صفحة الإصدار قد نشرت الملف و.asc وfort.keyring. تطابق النسخ الملتقطة في 31 أغسطس قيم SHA-256 الحالية في API، وأعاد GnuPG النتيجتين GOODSIG وVALIDSIG للبصمة 8F9ABC7EF3BA565F9DF1578C72160FD57B242967.
  • هذه نتيجة قوية لصحة العلاقة الرياضية بين الملف والمفتاح المرفق، وليست قرار ثقة كاملًا: أعادت البيئة نفسها TRUST_UNDEFINED، وكان الإصدار موصوفاً بأنه غير ثابت immutable: false وقت الرصد.
  • ينبغي لوصل التثبيت بسند قابل للتدقيق أن يسجل الإصدار وcommit، واسم الأصل وملخصه، ومصدر البصمة المستقل، ومدخلات البناء، وملخص الملف التنفيذي، ووقت التفعيل، وخطة الرجوع.

التوقيع الجيد يجيب عن سؤال واحد

تُغري صفحة الإصدار القارئ بإجابة مختصرة: هناك ملف، وبجواره توقيع، وبجواره مفتاح عام؛ إذن الملف موثوق. لكن هذه العبارة تضغط سؤالين مختلفين في نتيجة واحدة.

السؤال الأول رياضي: هل وُقّع الملف بالسر المقابل للمفتاح العام الذي استوردناه؟ يمكن لأداة GnuPG أن تجيب عنه. والسؤال الثاني مؤسسي: من يسيطر على ذلك المفتاح، ولماذا يحق له إصدار FORT، ومن أين حصل المشغّل على هذه المعلومة؟ لا ينشأ جواب السؤال الثاني تلقائياً من تنزيل المفتاح والتوقيع والملف من الصفحة نفسها.

دليل LACNIC المؤلف من ثماني صفحات لا يصل حتى إلى السؤال الأول. فهو يحدد FORT 1.7.0.experimental وUbuntu Server 26.04 ومعمارية amd64/x86_64، ويقول إن حزمة .deb المختبرة طلبت libmicrohttpd12 وlibxml2 بينما وفر النظام حزماً بأسماء مختلفة. لذلك اختار المؤلف البناء من المصدر باستعمال مكتبات التطوير الأصلية. لم تعِد هذه المراجعة تجربة مشكلة الحزمة؛ إنها تنسبها إلى الاختبار الموصوف في الدليل.

تبدأ الوصفة بتنزيل fort-1.7.0.experimental.tar.gz، ثم tar -xzf، فـ./configure وmake -j"$(nproc)" وsudo make install. بعد ذلك يفحص الدليل fort --version وldd، ويجري تحققاً أولياً، ويفحص المخرجات، ويضبط الخدمة وRTR، وينبّه إلى تزامن الساعة.

هذه اختبارات مفيدة بعد إدخال المصدر إلى النظام. لكنها لا تثبت هوية ما أُدخل. لا توجد قيمة SHA-256، ولا checksum، ولا إشارة إلى .asc أو keyring، ولا أمر gpg --verify. والموضع المتعلق بالتوقيع في النص الإسباني يشرح كائنات RPKI الموقعة، لا توقيع حزمة البرنامج. كما أن وثيقة التثبيت المثبتة على commit الإصدار تنزّل الحزم أو المصدر وتثبتهما من دون فحص ملخص أو توقيع منفصل.

المفتاح المرفق يثبت النتيجة ولا يؤسس الثقة وحده

تسجل GitHub إنشاء الإصدار 1.7.0.experimental في 16 يوليو 2026 عند 01:52:42Z ونشره عند 03:45:33Z. يشير الوسم المشروح إلى commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e؛ وتقول API لكائن الوسم إن توقيعه valid وverified.

أضيف الملف المضغوط عند 03:47:16Z، وتوقيعه المنفصل عند 03:47:19Z، وfort.keyring عند 03:51:35Z. سبقت العناصر الثلاثة دليل 10 أغسطس، فلم تكن المادة اللازمة للتحقق غائبة وقت تحريره.

في رصد 31 أغسطس، كانت الملخصات المنشورة كما يلي:

الأصل SHA-256
fort-1.7.0.experimental.tar.gz 70075f82effe5cf9752b13463f50c4379fdf93e5c28bdf6cba04e9621e2288cc
ملف .asc e648b9ff2075c6d78f4bf1a69c96a5b421757432b71f916a3118fb11ffe815ad
fort.keyring 8e4dfee468ad756bc89ffff3894692e87e66ffbd135dc697f3ffbac02116e6a6

تطابقت البايتات الملتقطة بصورة منفصلة مع القيم الثلاث الحالية في API. وعند استيراد حلقة المفاتيح المرفقة والتحقق من .asc مقابل الملف المضغوط، أعاد GnuPG GOODSIG وVALIDSIG. البصمة الأساسية هي 8F9ABC7EF3BA565F9DF1578C72160FD57B242967، ويحمل التوقيع توقيت 16 يوليو عند 01:55:02Z.

يجب قول الدفاع الأقوى بلا تردد: الملف الذي فُحص يطابق الملخص الحالي، وتوقيعه صحيح رياضياً تحت المفتاح العام المرفق. لا تعرض الأدلة ملفاً خبيثاً أو مستبدلاً أو خاطئاً، ولا تشير إلى فشل RPKI أو تسرب مسار أو اختطاف.

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

أربعة انتقالات تحتاج إلى أربعة إيصالات

يربط التوقيع على الوسم الوسم بـcommit c67d14b…. لكنه لا يثبت تلقائياً أن أصلاً منفصلاً رفع إلى Releases يحتوي ذلك commit بالضبط.

يربط سجل الإصدار اسم الأصل بوقت وملخص حاليين. وقد أظهرت API أيضاً immutable: false وdraft: false وprerelease: false. صفة غير ثابت لا تثبت أن الأصل تغيّر. إنها تفرض تأريخ الملاحظة وحفظها، ولا تسمح بجعل ملخص اليوم دليلاً على كل تنزيل تاريخي.

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

ويربط البناء المصدر بملف تنفيذي محلي عبر المترجم وخيارات configure والترويسات وإصدارات المكتبات. لا يمثل fort --version ملخص الملف، ولا يحتفظ ldd بكل مدخلات البناء. ولا تطرح المواد التي روجعت ادعاء بناء قابل لإعادة الإنتاج بايتاً ببايت.

أهمية الفصل تظهر مع sudo make install. الأمر يمنح نتيجة البناء سلطة الكتابة إلى النظام. لا يثبت ذلك أن النتيجة خطرة؛ بل يجعل من الضروري تسجيل أي نتيجة نالت السلطة.

سجل ثقة صغير يكفي لإغلاق معظم الفجوة

قبل فك الضغط، يستطيع الدليل تسمية الوسم وcommit وURL الأصل بدقة، ونشر SHA-256 المتوقع وحساب المرصود، والحصول على البصمة الكاملة من قناة موثقة مستقلة، والتحقق من .asc. وينبغي أن يكون الفشل قراراً واضحاً: التوقف، وحفظ الدليل، وطلب تصحيح.

بعد البناء، يمكن لسجل موجز أن يحفظ:

الحد الحد الأدنى من السجل
الإصدار الوسم، URL، commit، وقت النشر، وحالة الثبات المرصودة
الأصل الاسم وURL، الملخص المتوقع والمرصود، وقت التنزيل والفحص
الثقة ملخصا .asc وkeyring، البصمة، مصدر مستقل، قرار الثقة والنتيجة
البناء النظام، المعمارية، المترجم، الخيارات، وأسماء وإصدارات الاعتمادات
التثبيت مسار الملف التنفيذي وملخصه، النسخة، وملخصا الإعداد والخدمة
التشغيل وقت التفعيل، النسخة السابقة، الرجوع، تدوير/إلغاء المفتاح، والتصحيحات

لا يجعل هذا LACNIC سلطة منفردة. يدير مشروع FORT إصداراته، وتدير GitHub سطح توزيع، ويوفر Ubuntu الاعتمادات، ويقرر كل مشغّل جذر الثقة وسياسة التوجيه. تستطيع LACNIC، ضمن نطاقها، أن تجعل نقاط التسليم ظاهرة في الدليل الذي توصي به.

حدود الاستنتاج تحمي دقة النقد

الغياب في التعليمات العامة، لا في سلوك كل قارئ. قد تكون شبكة ما تحققت من الملخصات أو استخدمت مرآة داخلية أو مفتاحاً معتمداً أو خط بناء مضبوطاً. لا يمكن معرفة ذلك من PDF.

ولا تعني immutable: false أن أصلاً تغيّر. لا يثبت ملخص اليوم محتوى كل تنزيل سابق. ولا يثبت توقيع جيد تحت المفتاح المرفق الهوية القانونية للموقع. لا يوجد أساس لادعاء اختراق أو استبدال أو أثر في التوجيه.

كذلك لا يكرر الموضوع تحليل خرج ASPA أو تفاوض نسخة RTR بين FORT والراوتر. تلك حدود خرج البرنامج. هنا الحد أسبق: كيف ربط المشغّل البرنامج الذي يصنع الخرج بأصل وبمفتاح مخولين؟

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

المصادر