491 / 736REPRO

Reproducible Firmware Build

بناء قابل لإعادة الإنتاج للبرنامج الثابت

عند تحديث محفظة مادية، تثبّت ملفًا جاهزًا. لكن كيف تعرف أنه أُنتج فعلًا من الشيفرة التي نشرها المصنّع؟ يتيح Reproducible Firmware Build لشخص مستقل بناء البرنامج نفسه ومقارنة النتائج. وهكذا يساعد في التحقق من الصلة بين الشيفرة المنشورة والتحديث الموزّع.

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

يمكن للمصنّع نشر شيفرة يقرأها المبرمج. لكن ما تثبّته عادة في المحفظة هو ملف جاهز بصيغة تفهمها الآلة، يُسمى ملفًا ثنائيًا. عملية البناء هي الخطوة التي تصل بين الشكلين. يستطيع شخص مستقل تكرارها ومقارنة الناتج بالإصدار المنشور. يبحث عن تطابق البايتات، وهي وحدات البيانات، مثلًا باستخدام دالة تجزئة تشفيرية تنتج بصمة محسوبة من المحتوى. ينطبق التحقق على مخرجات محددة، كملف البرنامج الثابت، وليس تلقائيًا على كل ملفات العمل والسجلات. [1] [4]

تخيّل مطوّرَين يريدان فحص تحديث واحد. اسم المشروع وحده لا يكفي؛ يحتاجان إلى commit نفسه، أي مراجعة محددة بدقة للشيفرة. ويحتاجان كذلك إلى إصدارات المكتبات المستخدمة والمترجم البرمجي، وهو الأداة التي تحول الشيفرة إلى صيغة الآلة. خيارات هذه الأداة وإعدادات البيئة ذات الصلة وطراز المحفظة جزء من الإجراء أيضًا. يجب تحديد هذه المعلومات مسبقًا أو تسجيلها أثناء البناء. وإلا فقد يعمل الاثنان بأمانة ويحصل كل منهما على نتيجة مختلفة. [1] [2]

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

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

تشرح وثائق Trezor اختيار الإصدار والطراز، وبناء البرنامج الثابت ومقارنته بالملف الرسمي. ولأن الناتج المحلي لا يحمل توقيعًا مثل إصدار المصنّع، ينص الإجراء على تصفير حقول توقيع محددة بدقة قبل المقارنة. وتختلف الصيغ القديمة أيضًا في الترويسات، وهي الأجزاء الأولى التي تحمل معلومات عن الملف. يتغير ترتيب هذه البيانات بحسب الطراز والإصدار؛ فلا يجوز نقل تعليمات جهاز إلى آخر دون تحقق. يُفحص التوقيع الأصلي بصورة مستقلة، ولا تحل مقارنة النسخ المعدّلة محل ذلك الفحص. [5]

يجب أولًا التأكد من مقارنة مراجعة الشيفرة نفسها والطراز نفسه ونسخة البرنامج الثابت نفسها. بعد ذلك تُفحص الأدوات والمكتبات والتحويلات المحددة للملف. ينبغي الاحتفاظ بالملفات الأصلية وسجل الاختلاف. قد يكون السبب خطأ في البيئة أو التعليمات، وقد يكون تغييرًا في البرنامج الموزّع. الاختلاف وحده لا يحدد السبب أو المسؤول. وما لم يُفسّر ويُعاد الفحص، فلا يصح وصف البناء بأنه متحقق منه. [1] [4]

إذا احتوت الشيفرة المنشورة أصلًا على خلل، فقد تعيد كل عملية بناء إنتاجه بدقة. وقد يضيف مترجم غير موثوق يستخدمه الجميع التعديل الخبيث نفسه إلى كل النتائج؛ إعادة استخدامه لا تعني فحص الأداة بصورة مستقلة. كما تحدّ المكونات الثنائية المغلقة مما يمكن إعادة بنائه من الشيفرة المتاحة. وتطابق ملف على الحاسوب لا يثبت أن المحفظة الموجودة أمامك أصلية أو أنها تشغّل هذا البرنامج فعلًا. التحقق من منشأ الملف جزء مهم من الأمان، وليس دليلًا شاملًا عليه. [6] [1]

تصبح عبارة «تم التحقق» مفيدة عندما تعرف مَن أجرى الفحص، وأي مراجعة بُنيت، ولأي طراز وبأي إجراء. ينبغي أن يذكر التقرير الملفات المقارنة ودالة التجزئة والنتائج والطريقة الدقيقة لمعالجة بيانات التوقيع. يستطيع آخرون عندئذ مراجعة العمل أو تكراره. وكلما زاد عدد الجهات المستقلة التي تعيد البناء، قلّ الاعتماد على ناشر واحد. ومع ذلك يبقى فحص الشيفرة وآلية التحديث والجهاز نفسه ضروريًا. [2] [4]

مثال · REPRO

نتيجتان متطابقتان وبصمة مختلفة

يبني مطوّران البرنامج الثابت من المراجعة نفسها للطراز نفسه وفي البيئة نفسها. تتطابق بصمتا SHA-256 لملفيهما، لكن بصمة الإصدار الرسمي الموقّع مختلفة. إذا كانت الوثائق تحدد حقول التوقيع بدقة، يطبّقان التحويل المقرر على نسخ ويعيدان المقارنة. يخص التطابق عندئذ المحتوى المحدد بهذه الطريقة. ما زال التوقيع الأصلي بحاجة إلى فحص مستقل؛ ولا يجوز ببساطة حذف الاختلافات الأخرى التي لم تُفسّر.

للحصول على صورة أوضح، اقرأ هذا المدخل مع Hardware Wallet, Private Key, Cold Storage, Secure Element. تشير إلى هذا المدخل أيضًا COLDCARD RNG Incident (2026).

01هل يجب أن أبني البرنامج الثابت بنفسي كمستخدم؟

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

02هل تعني بصمة مختلفة لتحديث موقّع وقوع هجوم؟

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

DOC · 001Reproducible Builds — Definitionتوثيق DOC · 002Reproducible Builds — Recording the environmentتوثيق DOC · 003Reproducible Builds — Build pathsتوثيق DOC · 004Reproducible Builds — Build infrastructure threatsتوثيق DOC · 005Trezor — Reproducible build verificationتوثيق DOC · 006Wheeler — Countering Trusting Trustمصدر أولي
تمت المراجعة: المصادر أولًا · ليست نصيحة استثمارية