On the Variability of Source Code in Maven Package Rebuilds
यह शोध पत्र इस धारणा की जांच करता है कि मेवेन (Maven) पैकेज के वैकल्पिक सुरक्षा-केंद्रित बिल्ड समान सोर्स कोड का उपयोग करते हैं, जिसमें यह पाया गया है कि बिल्ड-टाइम कोड जनरेशन एक्सटेंशन गैर-तुल्यता का प्राथमिक कारण हैं और यह इस पुनरुत्पादकता चुनौती को संबोधित करने के लिए रणनीतियों का सुझाव देता है।
मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें
कल्पना कीजिए कि आप एक विशाल, उच्च-सुरक्षा वाली बेकरी चलाते हैं। आप यह सुनिश्चित करना चाहते हैं कि शहर में बिकने वाली हर ब्रेड की लोफ (loaf) बिल्कुल एक ही रेसिपी और सामग्री से बनी हो, जिसमें कोई छिपी हुई चीज़ न हो। इसके लिए, आप केवल मूल बेकर पर भरोसा नहीं करते; बल्कि आप एक दूसरी, स्वतंत्र टीम को काम पर रखते हैं जो उसी रेसिपी कार्ड का उपयोग करके शून्य से ब्रेड बनाने का काम करती है। यदि दोनों ब्रेड देखने, स्वाद और गंध में बिल्कुल एक जैसी हैं, तो आप जानते हैं कि रेसिपी सुरक्षित है। यदि वे अलग हैं, तो आप जानते हैं कि कुछ गलत हुआ है—शायद मूल बेकर ने कोई गुप्त सामग्री मिला दी है, या रेसिपी कार्ड के साथ छेड़छाड़ की गई है।
यह मूल रूप से वही है जो गूगल और ओरेकल जैसी सॉफ्टवेयर कंपनियाँ मेवेन पैकेज (Maven packages) (जावा सॉफ्टवेयर के निर्माण खंड) के साथ करती हैं। वे अपने सोर्स कोड से सॉफ्टवेयर को "पुनर्निर्मित" (rebuild) करके उसकी सुरक्षा को सत्यापित करने की कोशिश करती हैं।
हालाँकि, जेन्स डिएट्रिच और बेहनाज़ हसनशाही के इस शोध पत्र ने एक अजीब समस्या की खोज की है: कभी-कभी, मूल डेवलपर द्वारा प्रदान किए गए और स्वतंत्र पुनर्निर्माताओं द्वारा उपयोग किए गए "रेसिपी कार्ड" (सोर्स कोड) वास्तव में एक जैसे नहीं होते, भले ही वे ऐसा दावा करते हों।
यहाँ उनके द्वारा की गई खोज का एक सरल विवरण दिया गया है, जिसमें रोजमर्रा के उदाहरणों का उपयोग किया गया है।
1. "जादुई रेसिपी" की समस्या
शोधकर्ताओं ने 28 लोकप्रिय सॉफ्टवेयर पैकेजों का अध्ययन किया। उन्हें उम्मीद थी कि यदि दो टीमें एक ही सोर्स कोड से शुरुआत करती हैं, तो उन्हें एक ही परिणाम मिलेगा। लेकिन उन्होंने पाया कि कई मामलों में सोर्स कोड स्वयं अलग था।
क्यों? क्योंकि आधुनिक सॉफ्टवेयर अक्सर "जादुई रेसिपी जनरेटर" (Magic Recipe Generators) का उपयोग करते हैं।
कल्पना कीजिए कि एक बेकर केवल एक रेसिपी का पालन नहीं करता है, बल्कि उसके पास एक रोबोट है जो ओवन गर्म होने के दौरान ही रेसिपी का एक हिस्सा लिख देता है।
- रोबोट (बिल्ड प्लगइन्स): सॉफ्टवेयर में, ये वे उपकरण हैं जो बिल्ड प्रक्रिया के दौरान स्वचालित रूप से कोड लिखते हैं।
- समस्या: यदि रोबोट एक लाइन लिखता है "मंगलवार को दोपहर 2:00 बजे बेक किया गया," तो स्वतंत्र बेकर का रोबोट "बुधवार को दोपहर 3:00 बजे बेक किया गया" लिखेगा। भले ही ब्रेड एक ही हो, लेकिन रेसिपी कार्ड अलग दिखेंगे क्योंकि उनमें टाइमस्टैम्प (समय का विवरण) अलग है।
2. तीन मुख्य अपराधी
पेपर ने इन "रेसिपी कार्डों" के मेल न खाने के तीन मुख्य कारणों की पहचान की:
"स्वयं को शामिल करने वाला" रोबोट (कोड जनरेशन):
कुछ उपकरण चलते समय (on the fly) कोड जनरेट करते हैं। उदाहरण के लिए, एक टूल उपयोग की गई सभी सामग्रियों की सूची बना सकता है। यदि वह टूल थोड़े अलग समय पर चलता है या खुद के थोड़े अलग संस्करण का उपयोग करता है, तो वह जो सूची बनाता है उसका क्रम अलग हो सकता है। यह दो शेफ की तरह है जो सूप के लिए सामग्री लिख रहे हैं; एक लिखता है "नमक, काली मिर्च, गाजर," और दूसरा लिखता है "गाजर, नमक, काली मिर्च।" सूप का स्वाद एक जैसा है, लेकिन लिखित सूची अलग है।- वास्तविक उदाहरण: विशिष्ट भाषाओं के लिए पार्सर (parsers) बनाने वाले या API दस्तावेज़ीकरण (documentation) बनाने वाले टूल्स अक्सर ऐसा करते हैं।
"शेडेड" बॉक्स (शेडिंग - Shading):
कभी-कभी, टकरावों से बचने के लिए, एक बेकर सार्वजनिक टूल के बजाय बॉक्स के अंदर अपना निजी संस्करण रखता है। इसे "शेडिंग" कहा जाता है।- गलतफहमी: मूल बेकर बॉक्स के अंदर "प्राइवेट ब्रांड" का आटा इस्तेमाल कर सकता है, जबकि स्वतंत्र पुनर्निर्माता "पब्लिक ब्रांड" का उपयोग करने की कोशिश करता है क्योंकि उसे पता नहीं था कि निजी वाले की आवश्यकता थी। इससे अलग सामग्री का उपयोग होता है, जिसके परिणामस्वरूप अलग ब्रेड बनती है।
कुकबुक का "गलत पेज" (असंगत कमिट्स - Inconsistent Commits):
कभी-कभी, स्वतंत्र टीम कुकबुक से गलत पेज उठा लेती है। डेवलपर ने ब्रेड प्रकाशित करने के बाद रेसिपी को अपडेट कर दिया होगा, लेकिन स्वतंत्र टीम ने रेसिपी का नया संस्करण ले लिया, जबकि मूल ब्रेड पुराने संस्करण से बनाई गई थी।- परिणाम: वे सेब की तुलना संतरे से कर रहे हैं क्योंकि वे दो अलग-अलग संस्करणों के सोर्स कोड को देख रहे हैं।
3. आपको इसकी परवाह क्यों करनी चाहिए?
आप सोच सकते हैं, "यदि ब्रेड का स्वाद एक जैसा है, तो रेसिपी कार्ड थोड़ा अलग होने से किसे फर्क पड़ता है?"
सॉफ्टवेयर सुरक्षा की दुनिया में, रेसिपी कार्ड ही सब कुछ है।
- छिपा हुआ मैलवेयर (Malware): यदि कोई हैकर "जादुई रोबोट" (बिल्ड प्लगइन) से समझौता कर लेता है, तो वे ऐसा हानिकारक कोड डाल सकते हैं जो केवल अंतिम उत्पाद में दिखाई देता है लेकिन दिखने वाले सोर्स कोड में नहीं होता है।
- टूटा हुआ विश्वास: यदि हम यह सत्यापित नहीं कर सकते कि सोर्स कोड अंतिम उत्पाद से मेल खाता है या नहीं, तो हम सॉफ्टवेयर की सुरक्षा पर भरोसा नहीं कर सकते। यह कार खरीदने जैसा है और आपसे कहा जाना कि, "हम पर भरोसा करें, इंजन सुरक्षित है," लेकिन आप ब्लूप्रिंट की जांच नहीं कर सकते क्योंकि वे कार से मेल नहीं खाते।
4. प्रस्तावित समाधान: एक बेहतर "स्टिकी नोट"
लेखक एक समाधान का सुझाव देते हैं। वर्तमान में, सॉफ्टवेयर में एक "स्टिकी नोट" होता है जिसे @Generated कहा जाता है जो कहता है, "हे, यह कोड का हिस्सा एक रोबोट द्वारा लिखा गया था।" लेकिन यह नोट दोषपूर्ण है:
- इसमें अक्सर समय और तारीख शामिल होती है (जिससे यह हर बार बदल जाता है)।
- इसे सुरक्षा स्कैनरों के लिए पढ़ना कठिन है।
- यह यह नहीं बताता कि किस रोबोट ने कोड लिखा या उस रोबोट का संस्करण (version) क्या था।
समाधान: वे इस स्टिकी नोट को एक डिजिटल पासपोर्ट की तरह अपग्रेड करने का प्रस्ताव देते हैं।
- इसे ठीक-ठीक बताना चाहिए कि किस टूल ने कोड जनरेट किया।
- इसमें उस टूल का संस्करण शामिल होना चाहिए।
- इसमें समय या तारीख शामिल नहीं होनी चाहिए।
इस तरह, सुरक्षा उपकरण कोड को देख सकते हैं, "पासपोर्ट" देख सकते हैं, और कह सकते हैं, "आह, यह कोड टूल X द्वारा जनरेट किया गया था, संस्करण 1.0। मैं जानता हूँ कि टूल X की एक खामी है जहाँ वह सामग्री का क्रम बदल देता है। मैं उस अंतर को अनदेखा कर दूँगा और फिर भी ब्रेड को सुरक्षित मानूँगा।"
सारांश
यह पेपर एक चेतावनी है कि सॉफ्टवेयर सुरक्षा की हमारी वर्तमान जांच थोड़ी ऐसी है जैसे दो हाथ से लिखी रेसिपी की तुलना करना, जब उनमें से एक रोबोट द्वारा लिखी गई हो जो हर बार पलक झपकने पर अपनी लिखावट बदल देता है।
लेखकों ने पाया है कि बिल्ड-टाइम कोड जनरेशन ही इन रेसिपीओं के मेल न खाने का मुख्य कारण है। इसे ठीक करने के लिए, हमें यह ट्रैक करने के लिए बेहतर उपकरण चाहिए कि कोड वास्तव में कैसे और किसके द्वारा जनरेट किया गया था, ताकि हम भरोसा कर सकें कि हमारा सॉफ्टवेयर सप्लाई चेन के साथ छेड़छाड़ नहीं की गई है।
अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?
आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।