← नवीनतम पेपर
💻 computer science

No Snake Oil: Verifying Python Package Builds

यह शोध पत्र daleq4py का परिचय देता है, जो एक ऐसा टूल है जो पायथन पैकेज व्हील्स (Python package wheels) को सामान्य करने के लिए प्रोवेनेंस-प्रिजर्विंग डैटलॉग नियमों (provenance-preserving datalog rules) का उपयोग करता है, जो macaron और oss-rebuild जैसे मौजूदा टूल्स की तुलना में सत्यापित बिल्ड समानता (verified build equivalence) की दर को लगभग 15–19% से बढ़ाकर 60–78% से अधिक कर देता है।

मूल लेखक: Jens Dietrich, Spencer Sun, Tim W. White, Behnaz Hassanshahi

प्रकाशित 2026-07-27
📖 7 मिनट में पढ़ें🧠 गहराई से पढ़ें

मूल लेखक: Jens Dietrich, Spencer Sun, Tim W. White, Behnaz Hassanshahi

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

इंटरनेट की कल्पना एक विशाल, हलचल भरे शहर के रूप में करें जहाँ आपके द्वारा उपयोग किए जाने वाले प्रत्येक ऐप, वेबसाइट और AI चैटबॉट को पहले से बने हजारों लेगो ब्रिक्स (Lego bricks) को एक के ऊपर एक रखकर बनाया गया है। इन ब्रिक्स को "पैकेज" कहा जाता है, और इन्हें PyPI (पायथन पैकेज इंडेक्स) नामक एक विशाल सार्वजनिक गोदाम में रखा जाता है। क्योंकि आर्टिफिशियल इंटेलिजेंस बनाने के लिए पायथन सबसे पसंदीदा भाषा है, इसलिए यह गोदाम डिजिटल ग्रह के सबसे व्यस्त स्थानों में से एक है। लेकिन यहाँ एक पेंच है: ठीक वैसे ही जैसे एक वास्तविक शहर में होता है, बुरे तत्व गोदाम में घुसकर एक सुरक्षित लेगो ब्रिक को एक नकली ब्रिक से बदल सकते हैं जिसमें एक छिपा हुआ ट्रैपडोर (trapdoor) हो, और इसे लाखों निर्माताओं के पास भेज सकते हैं। इसे "सप्लाई चेन अटैक" (supply chain attack) कहा जाता है, और यह सुरक्षा के लिए एक बुरा सपना है।

इन जालसाजों को पकड़ने के लिए, सुरक्षा विशेषज्ञ एक चतुर तरकीब का उपयोग करते हैं: "रीबिल्डिंग" (rebuilding)। उस ब्रिक पर भरोसा करने के बजाय जो आपने खरीदा है, वे मूल निर्देशों (सोर्स कोड) पर वापस जाते हैं और खुद एक अत्यंत सुरक्षित, अलग लैब में उस ब्रिक को बनाने की कोशिश करते हैं। यदि उनका नया ब्रिक आपके द्वारा खरीदे गए ब्रिक के बिल्कुल समान दिखता है, तो वे जानते हैं कि वह सुरक्षित है। यदि वह अलग दिखता है, तो वह एक जाल हो सकता है। हालाँकि, इस अस्त-व्यस्त वास्तविक दुनिया में, ईमानदार निर्माता भी अक्सर ऐसे ब्रिक्स बनाते हैं जो मामूली कारणों से थोड़े अलग दिखते हैं—जैसे कि वह समय जब उन्होंने इसे बनाया था, टुकड़ों को जोड़ने का क्रम, या उनके द्वारा उपयोग किया गया विशिष्ट उपकरण। यह एक भ्रमित करने वाली समस्या पैदा करता है: आप यह कैसे पहचानें कि एक "हानिरहित रूप से भिन्न" ब्रिक और एक "खतरनाक नकली" ब्रिक के बीच क्या अंतर है, बिना हर एक सूक्ष्म विवरण की जांच किए?

यही वह विषय है जिसे शोध पत्र "No Snake Oil: Verifying Python Package Builds" संबोधित करता है। शोधकर्ताओं ने, जो Oracle और Victoria University of Wellington के उपकरणों के साथ काम कर रहे थे, इन परिस्थितियों को परखने के लिए 12,000 से अधिक लोकप्रिय पायथन पैकेज को शून्य से फिर से बनाने (rebuild) का परीक्षण करने का निर्णय लिया। वे यह देखना चाहते थे कि वे कितनी बार मूल ब्रिक्स को पूरी तरह से पुन: निर्मित कर सकते हैं और, अधिक महत्वपूर्ण बात यह है कि, यह कैसे पता लगाया जाए कि एक "अलग दिखने वाला" ब्रिक वास्तव में सुरक्षित था।

द ग्रेट रीबिल्ड एक्सपेरिमेंट (The Great Rebuild Experiment)

टीम ने इन पैकेजों को फिर से बनाने की कोशिश करने के लिए Macaron और oss-rebuild नामक दो अलग-अलग स्वचालित रोबोटों का उपयोग किया। इन रोबोटों को दो अलग-अलग शेफ के रूप में समझें जो एक ही रेसिपी से बिल्कुल एक जैसा केक बनाने की कोशिश कर रहे हैं। पहला प्रश्न जो उन्होंने पूछा था, वह था: "क्या वे केक बना भी पाएंगे?"

परिणाम मिले-जुले रहे। 10,449 शुद्ध-पायथन पैकेजों (जिनमें जटिल, प्री-कंपाइल्ड हिस्से शामिल नहीं थे) में से जिन्हें टीम ने फिर से बनाने की कोशिश की, Macaron ने उनमें से 68% को सफलतापूर्वक बनाया, जबकि oss-rebuild केवल 56.5% ही बना सका। रोबोट मुख्य रूप से इसलिए विफल हुए क्योंकि उन्हें सही रेसिपी (सोर्स कोड) नहीं मिली, वे गायब सामग्रियों (dependencies) के कारण भ्रमित हो गए, या वे यह नहीं समझ सके कि किस ओवन के संस्करण का उपयोग करना है। यह स्पष्ट है कि एक इंसान की निर्माण प्रक्रिया की सटीक नकल करने के लिए एक रोबोट को तैयार करना आश्चर्यजनक रूप से कठिन है।

"परफेक्ट मैच" की समस्या (The "Perfect Match" Problem)

इसके बाद, शोधकर्ताओं ने सबसे सख्त प्रश्न पूछा: "क्या रोबots ने एक ऐसा केक बनाया है जो स्टोर में बेचे जा रहे केक के समान, कण-दर-कण (crumb for crumb) बिल्कुल वैसा ही है?" उन्होंने मूल केक के डिजिटल फिंगरप्रिंट्स (हैश) की तुलना पुन: निर्मित केक के साथ की।

इसका उत्तर एक कठोर वास्तविकता थी: नहीं। Macaron के केवल 15.4% और oss-rebuild के केवल 19.1% केक मूल के बिल्कुल समान (byte-for-byte identical) थे। अधिकांश केक अलग दिख रहे थे। यदि आप इस सख्त नियम का पालन करते कि "जो भी अलग है वह नकली है," तो आपको 80% केक फेंकने पड़ते, भले ही उनमें से अधिकांश शायद केवल थोड़े अलग ओवन तापमान या आटे के अलग ब्रांड के साथ बनाए गए हों। इससे "अलर्ट फटीग" (alert fatigue) पैदा होगा, जहाँ सुरक्षा विशेषज्ञों को इतने अधिक झूठे अलार्म मिलते हैं कि वे वास्तविक खतरों पर ध्यान देना बंद कर देते हैं।

"एक्सप्लेनेबल इक्विवेलेंस" का जादू (The Magic of "Explainable Equivalence")

यहीं पर यह शोध पत्र अपना मुख्य पात्र पेश करता है: एक नया टूल जिसे daleq4py कहा जाता है। एक पूर्ण, पिक्सेल-परफेक्ट मिलान की मांग करने के बजाय, यह टूल एक स्मार्ट फूड क्रिटिक की तरह काम करता है जो समझता है कि एक केक का स्वाद एक जैसा हो सकता है भले ही फ्रॉस्टिंग का पैटर्न अलग हो या स्प्रिंकल्स का रंग थोड़ा अलग नीला हो।

यह टूल "नॉर्मलाइज़" (normalize) करने के लिए Datalog नामक भाषा में लिखे गए विशेष नियमों के सेट का उपयोग करता है। यह हानिरहित अंतरों को हटा देता है—जैसे कि केक बनाने का समय, सामग्री की सूची का क्रम, या मिक्सिंग बाउल का विशिष्ट ब्रांड—जबकि इसके मूल ढांचे को बरकरार रखता है। इसके बाद यह केक के "सार" (essence) की तुलना करता है।

इसके परिणाम क्रांतिकारी थे। जब शोधकर्ताओं ने यह जांचने के लिए daleq-4py का उपयोग किया कि कौन से केक परफेक्ट मैच नहीं थे, तो उन्होंने पाया कि:

  • Macaron के लिए, "अलग दिखने वाले" केक में से 60.2% वास्तव में मूल के समान (equivalent) थे।
  • oss-rebuild के लिए, 78.9% समान थे।

इसका अर्थ यह है कि इस स्मार्ट टूल का उपयोग करके, जिन्हें "सुरक्षित" माना जा सकता है, उन रीबिल्ड्स की संख्या लगभग 5 में से 1 से बढ़कर लगभग 5 में से 3 या 4 हो जाती है।

यह क्यों महत्वपूर्ण है?

यह शोध पत्र यह दावा नहीं करता है कि इसने सप्लाई चेन सुरक्षा की समस्या को हमेशा के लिए हल कर दिया है। यह स्वीकार करता है कि अभी भी कुछ कमियां हैं, जैसे यह सुनिश्चित करना कि रोबोटों ने सही रेसिपी चुनी थी या नहीं (जो उन्होंने 96.3% बार सही ढंग से किया जब दोनों रोबोट सहमत थे)। यह यह भी नोट करता है कि "हानिरmless" क्या है, इसके नियमों को मनुष्यों द्वारा सावधानीपूर्वक जांचा जाना चाहिए ताकि कोई भी बुरा तत्व एक ऐसा नकली केक न घुसा सके जो "नॉर्मलाइज्ड" दिखता हो लेकिन वास्तव में ज़हरीला हो।

हालाँकि, यह अध्ययन सिद्ध करता है कि हमें "अच्छे के साथ बुरे को" (throw out the baby with the bathwater) फेंकने की आवश्यकता नहीं है। यह स्वीकार करके कि "अलग" होने का मतलब हमेशा "खतरनाक" होना नहीं है, और daleq4py जैसे उपकरणों का उपयोग करके यह समझाने के लिए कि दो अलग दिखने वाले पैकेज वास्तव में एक ही क्यों हैं, हम शोर (noise) को काफी कम कर सकते हैं। यह सुरक्षा टीमों को हानिरहित विविधताओं की चिंता करने के बजाय अपनी ऊर्जा उन कुछ वास्तव में संदिग्ध अंतरों पर केंद्रित करने की अनुमति देता है जो वास्तव में मैलवेयर हो सकते हैं। यह "सब कुछ संदिग्ध है" की दुनिया से "हम जानते हैं कि क्या सुरक्षित है, और हम इसे साबित कर सकते हैं" की दुनिया की ओर एक कदम है।

अपने क्षेत्र के पेपरों की भीड़ में उलझे हुए हैं?

आपके रिसर्च कीवर्ड से मेल खाने वाले सबसे नए और अलग सोच वाले पेपरों का रोज़ाना Digest पाएँ—तकनीकी सारांश के साथ, आपकी भाषा में।

Digest आज़माएँ →