Reproducible Firmware Build

निर्माता ऐसा कोड प्रकाशित कर सकता है जिसे प्रोग्रामर पढ़ सके। मगर वॉलेट पर आम तौर पर एक तैयार, मशीन द्वारा पढ़ी जाने वाली फ़ाइल इंस्टॉल होती है, जिसे बाइनरी कहते हैं। इन दोनों रूपों के बीच का चरण बिल्ड है। कोई स्वतंत्र व्यक्ति उसे दोहरा सकता है और परिणाम की तुलना जारी फ़ाइल से कर सकता है। जाँच देखती है कि डेटा की इकाइयाँ, यानी बाइट, समान हैं या नहीं। इसके लिए अक्सर क्रिप्टोग्राफ़िक हैश इस्तेमाल होता है: सामग्री से निकाला गया एक तरह का डिजिटल निशान। दावा निर्धारित परिणामों, जैसे फ़र्मवेयर फ़ाइल, तक सीमित होता है; हर अस्थायी फ़ाइल और लॉग अपने-आप इसमें शामिल नहीं होते। [1] [4]

मान लें कि दो डेवलपर एक अपडेट जाँचना चाहते हैं। केवल परियोजना का नाम जानना पर्याप्त नहीं है। उन्हें एक ही commit चाहिए, यानी कोड का बिल्कुल निश्चित संस्करण। इस्तेमाल की गई लाइब्रेरी और कंपाइलर के संस्करण भी चाहिए। कंपाइलर वह औज़ार है जो कोड को मशीन के रूप में बदलता है। उसके विकल्प, संबंधित परिवेश सेटिंग और वॉलेट का मॉडल भी प्रक्रिया का हिस्सा हैं। ये बातें पहले से तय हों या बिल्ड के दौरान दर्ज की जाएँ। वरना दोनों लोग ईमानदारी से काम करके भी अलग फ़ाइलें बना सकते हैं। [1] [2]

अंतर का मतलब हमेशा यह नहीं कि किसी ने प्रोग्राम का व्यवहार बदल दिया। कंपाइलर त्रुटियाँ खोजने वाली जानकारी में अपने कार्य फ़ोल्डर का पथ दर्ज कर सकता है। दोनों डेवलपर परियोजना अलग स्थानों पर रखें तो फ़ाइलें इसी वजह से अलग हो सकती हैं। एक निर्धारित पथ या पथों को एक जैसा बनाने का समर्थित तरीका इसका समाधान हो सकता है। लेकिन यह नियम पहले से ज्ञात बिल्ड प्रक्रिया का हिस्सा होना चाहिए। असफल जाँच के बाद अनसमझे अंतर मिटाकर फ़ाइलें समान बना देना सत्यापन का उद्देश्य ही खत्म कर देता है। [3]

डिजिटल हस्ताक्षर से जाँचा जा सकता है कि फ़ाइल संबंधित कुंजी से बनाए गए हस्ताक्षर से मेल खाती है या नहीं। उस कुंजी को निर्माता की मानना भरोसे का एक और हिस्सा है। पुनरुत्पादनीय बिल्ड अलग प्रश्न पूछता है: क्या फ़ाइल निर्धारित स्रोत कोड से मेल खाती है? दोनों जाँचें एक-दूसरे की पूरक हैं। मगर आधिकारिक अपडेट में ऐसा हस्ताक्षर डेटा हो सकता है जो स्थानीय बिल्ड में नहीं है। फ़ॉर्मैट समझे बिना पूरी फ़ाइलों की तुलना करने पर सही तरीके से बने प्रोग्राम में भी अंतर दिख सकता है। [5]

Trezor के दस्तावेज़ संस्करण और मॉडल चुनने, फ़र्मवेयर बनाने और आधिकारिक फ़ाइल से तुलना करने की प्रक्रिया बताते हैं। स्थानीय परिणाम पर निर्माता की रिलीज़ जैसा हस्ताक्षर नहीं होता, इसलिए प्रक्रिया तुलना से पहले स्पष्ट रूप से निर्धारित हस्ताक्षर फ़ील्ड को शून्य करती है। पुराने फ़ॉर्मैट के हेडर भी अलग होते हैं; हेडर फ़ाइल का शुरुआती हिस्सा है जिसमें उसके बारे में जानकारी होती है। डेटा की संरचना मॉडल और संस्करण पर निर्भर है। इसलिए एक उपकरण के निर्देश बिना जाँच दूसरे पर लागू नहीं किए जा सकते। मूल हस्ताक्षर अलग से सत्यापित होता है; संशोधित प्रतियों की तुलना उसका विकल्प नहीं है। [5]

पहले देखें कि तुलना में वही कोड संस्करण, वही मॉडल और वही फ़र्मवेयर प्रकार इस्तेमाल हुए थे या नहीं। फिर औज़ार, लाइब्रेरी और फ़ाइल में निर्धारित बदलाव जाँचें। मूल फ़ाइलें और मिले अंतर का रिकॉर्ड सुरक्षित रखें। वजह परिवेश या निर्देश की गलती हो सकती है, या वितरित प्रोग्राम में बदलाव भी। केवल असमानता से न कारण पता चलता है, न जिम्मेदार व्यक्ति। अंतर समझाए जाने और जाँच दोहराए जाने तक बिल्ड को सत्यापित नहीं कहना चाहिए। [1] [4]

प्रकाशित कोड में पहले से त्रुटि हो तो हर नया बिल्ड उसे हूबहू दोहरा सकता है। सबके इस्तेमाल वाला अविश्वसनीय कंपाइलर भी हर परिणाम में एक ही दुर्भावनापूर्ण बदलाव जोड़ सकता है। उसका दोबारा इस्तेमाल करना उस औज़ार की स्वतंत्र जाँच करना नहीं है। बंद स्रोत वाले बाइनरी हिस्से भी सीमित करते हैं कि उपलब्ध कोड से क्या दोबारा बनाया जा सकता है। कंप्यूटर की फ़ाइल समान होने से यह नहीं पता चलता कि सामने रखा वॉलेट असली है या सचमुच वही फ़र्मवेयर चला रहा है। फ़ाइल की उत्पत्ति जाँचना सुरक्षा का महत्वपूर्ण भाग है, उसका संपूर्ण प्रमाण नहीं। [6] [1]

“सत्यापित” कहने वाली रिपोर्ट तभी उपयोगी है जब उसमें पता चले कि जाँच किसने की, कौन-सा कोड संस्करण बनाया, किस मॉडल के लिए और किस विधि से। तुलना की गई फ़ाइलें, हैश फ़ंक्शन, परिणाम और हस्ताक्षर डेटा का सटीक व्यवहार भी दर्ज होना चाहिए। तब दूसरे लोग काम की समीक्षा या उसे दोहरा सकते हैं। अधिक स्वतंत्र बिल्ड करने वालों से एक ही प्रकाशक पर निर्भरता घटती है। फिर भी कोड, अपडेट प्रक्रिया और उपकरण की जाँच अलग से आवश्यक रहती है। [2] [4]