डेवलपर टूल · SHA हैश कैलकुलेटर
सामग्री का पता: Git, Docker और npm नाम के रूप में SHA डाइजेस्ट का उपयोग कैसे करते हैं
· पेजभूमि
शा-256 डाक में काम करनेवाला मज़दूर क्रिप्टोग्राफी डेवलपर-वर्कफ़्लो
Git कमिट, कंटेनर इमेज डाइजेस्ट और लॉकफ़ाइल इंटीग्रिटी स्ट्रिंग्स सभी एक ही विचार हैं: डेटा को उसके हैश द्वारा नामकरण करना। यह पोस्ट सामग्री को संबोधित करने और प्रत्येक पारिस्थितिकी तंत्र को इससे क्या लाभ मिलता है, इसकी व्याख्या करता है।
sha256: आपके Docker पुल में - वह स्ट्रिंग क्या है और यह एक ही छवि के लिए कभी क्यों नहीं बदलती है
संस्करण नियंत्रण प्रणालियाँ, कंटेनर रनटाइम और पैकेज प्रबंधक सभी एक ही नामकरण विचार का उपयोग करते हैं: एक फ़ाइल या बाइट्स के संग्रह का नाम उसके SHA डाइजेस्ट द्वारा रखा जाता है। Git में, एक कमिट के 40-कैरेक्टर SHA-1 पहचानकर्ता (या आधुनिक रिपॉजिटरी में 64-कैरेक्टर SHA-256) की गणना कमिट की सामग्री - ट्री, लेखक, टाइमस्टैम्प और संदेश से की जाती है। एक बाइट बदलें और SHA बदल जाता है। Docker में, प्रत्येक लेयर डाइजेस्ट परत की सामग्री का SHA-256 हैश है, और इमेज डाइजेस्ट की गणना मेनिफेस्ट से की जाती है। एनपीएम और अन्य पैकेज प्रबंधकों में, अखंडता फ़ील्ड डाउनलोड को सत्यापित करने के लिए टारबॉल के SHA-512 डाइजेस्ट को संग्रहीत करते हैं। कंटेंट एड्रेसिंग का मतलब है कि नाम केवल बाइट्स पर निर्भर करता है, केंद्रीय डेटाबेस या टाइमस्टैम्प पर नहीं।
लाभ प्रत्येक प्रणाली के भीतर अपरिवर्तनीयता है। एक git कमिट SHA-256:abc... हमेशा एक ही पेड़ और संदेश को संदर्भित करेगा क्योंकि हैश पहचान निर्धारित करता है। यदि कोई एक ही SHA के साथ एक अलग प्रतिबद्धता का दावा करता है, तो वे दावा कर रहे हैं कि एक ही बाइट्स दो अलग-अलग हैश उत्पन्न करते हैं, जो क्रिप्टोग्राफी को तोड़ देता है। डीडुप्लीकेशन स्वचालित हो जाता है: समान बाइट्स वाली दो फ़ाइलें समान डाइजेस्ट उत्पन्न करती हैं, इसलिए स्टोरेज सिस्टम बाइट्स को एक बार संग्रहीत कर सकते हैं और उन्हें दो बार संदर्भित कर सकते हैं। सत्यनिष्ठा की जाँच करना डाइजेस्ट की पुनः गणना करने और तुलना करने जितना सरल हो जाता है: यदि बाइट्स को ट्रांज़िट में या विश्राम के दौरान संशोधित किया गया था, तो डाइजेस्ट अब मेल नहीं खाता है।
डेटा को उसके हैश द्वारा नाम देना - सामग्री-संबोधन विचार और यह डुप्लीकेशन और अखंडता को मुक्त क्यों बनाता है
Git वस्तुओं-कमिट्स, ट्री, ब्लॉब्स और टैग्स को उनके SHA डाइजेस्ट द्वारा कुंजीबद्ध करके संग्रहीत करता है। `git cat-file` कमांड एक ऑब्जेक्ट ID लेता है और बाइट्स पुनर्प्राप्त करता है। ऑब्जेक्ट स्टोर सामग्री-संबोधित है: आप डाइजेस्ट द्वारा अनुरोध करते हैं, स्थान या नाम से नहीं। जब आप किसी रिपॉजिटरी को क्लोन करते हैं, तो git प्रत्येक ऑब्जेक्ट को उसके डाइजेस्ट की पुनः गणना करके और ट्रांसफर में पैक किए गए डाइजेस्ट के विरुद्ध जाँच करके सत्यापित करता है। SHA-1 से SHA-256 तक संक्रमण क्रमिक है; अनुकूलता के लिए रिपॉजिटरी दोनों का समर्थन कर सकती है। ऑन-डिस्क प्रारूप ऑब्जेक्ट प्रकार, आकार और संपीड़ित बाइट्स को संग्रहीत करता है। डाइजेस्ट की गणना विहित असम्पीडित रूप में की जाती है।
आधुनिक Git रिपॉजिटरी SHA-256 का उपयोग कर सकते हैं, और संक्रमण जारी है क्योंकि SHA-1 टकराव अब व्यावहारिक हैं (2017 में प्रदर्शित और 2020 में परिष्कृत)। SHA-256 का उपयोग करने वाली रिपॉजिटरी में एक कमिट में 40 के बजाय 64-वर्ण हेक्स पहचानकर्ता होता है। `git hash-object` कमांड किसी ब्लॉब (फ़ाइल सामग्री) को संग्रहीत किए बिना SHA की गणना करता है; `git commit-tree` एक वृक्ष संरचना और संदेश के SHA की गणना करता है। दोनों ऑपरेशन नियतात्मक हैं: समान बाइट्स हमेशा एक ही डाइजेस्ट उत्पन्न करते हैं। इस प्रकार GitHub और अन्य फोर्ज प्रतिबद्ध SHAs को लगातार प्रदर्शित कर सकते हैं - वे लेखक के क्लोन की गणना के समान ही डाइजेस्ट की गणना करते हैं।
Git सामग्री-संबोधित ऑब्जेक्ट का उपयोग करता है और यह टूल टेक्स्ट डाइजेस्ट को पुन: उत्पन्न कर सकता है; माइग्रेशन विवरण के लिए Git-विशिष्ट स्रोतों की आवश्यकता होती है
Docker छवियां परतों में बनाई गई हैं, जहां प्रत्येक परत एक फ़ाइल सिस्टम डेल्टा है (पिछली परत से परिवर्तन)। OCI इमेज स्पेक परिभाषित करता है कि एक परत के डाइजेस्ट और इमेज मेनिफ़ेस्ट के डाइजेस्ट की गणना कैसे की जाए। लेयर डाइजेस्ट, लेयर फ़ाइलों वाली संपीड़ित टार फ़ाइल का SHA-256 है। मेनिफेस्ट एक JSON दस्तावेज़ है जो परतों, उनके डाइजेस्ट और मेटाडेटा को सूचीबद्ध करता है। इमेज डाइजेस्ट मेनिफेस्ट JSON का SHA-256 ही है। जब आप `latest` जैसे टैग का उपयोग करके एक छवि खींचते हैं, तो रजिस्ट्री टैग को देखती है और मैनिफ़ेस्ट डाइजेस्ट लौटाती है। फिर आप सीधे डाइजेस्ट द्वारा खींच सकते हैं, यह सुनिश्चित करते हुए कि आपको हर बार बिल्कुल समान बाइट्स - सभी परतें और मेटाडेटा - मिलें।
स्थानीय छवि पर `docker inspect` कमांड इसका डाइजेस्ट दिखाता है। दो मशीनों पर एक ही टैग से एक ही छवि चलाने से एक ही डाइजेस्ट उत्पन्न होता है यदि रजिस्ट्री अभी भी उस टैग को उसी मैनिफ़ेस्ट की ओर इंगित करती है। कंटेंट एड्रेसिंग छवि आपूर्ति श्रृंखलाओं को ऑडिट करने योग्य बनाता है: एक CI/CD पाइपलाइन यह सत्यापित कर सकती है कि जिस छवि को उसने तैनात किया है वह बिल्ड लॉग में डाइजेस्ट से मेल खाती है, और एक सुरक्षा स्कैनर टैग के बजाय उनके डाइजेस्ट द्वारा विशिष्ट भेद्यता वाली सभी छवियों पर रिपोर्ट कर सकता है, जो स्थानांतरित हो सकती हैं।
कंटेनर - OCI मैनिफ़ेस्ट और लेयर डाइजेस्ट, और एक टैग क्यों चल सकता है लेकिन डाइजेस्ट नहीं चल सकता
पैकेज प्रबंधक छेड़छाड़ या भ्रष्टाचार के विरुद्ध डाउनलोड को सत्यापित करने के लिए डाइजेस्ट का उपयोग करते हैं। एनपीएम में, `package-lock.json` फ़ाइल में प्रत्येक निर्भरता के लिए एक `integrity` फ़ील्ड शामिल होती है, जिसमें एक हैश (आमतौर पर SHA-512) और एन्कोडिंग (आमतौर पर Base64) होता है। जब एनपीएम टारबॉल डाउनलोड करता है, तो यह हैश की पुनः गणना करता है और तुलना करता है। यदि हैश मेल नहीं खाता है, तो इंस्टॉल विफल हो जाता है। गो समान संरचना वाली `go.sum` फ़ाइल का उपयोग करता है: मॉड्यूल पथ, संस्करण और मॉड्यूल स्रोत का SHA-256। कार्गो `Cargo.lock` में चेकसम का उपयोग करता है। सिद्धांत समान है: डाइजेस्ट की गणना एक बार की जाती है जब निर्भरता पहली बार हल हो जाती है, और प्रत्येक बाद की स्थापना पर जाँच की जाती है।
सत्यनिष्ठा जाँच के लिए पैकेज को हस्ताक्षर प्राधिकारी के पास अपलोड करने या हस्ताक्षरों को अलग से संग्रहीत करने की आवश्यकता नहीं होती है। डाइजेस्ट अखंडता जांच है. अधिकतम आश्वासन के लिए, परियोजनाएँ `go.sum` का उपयोग करती हैं जो गो परियोजना की पारदर्शिता प्रणाली, या अन्य सत्यापन के साथ संयुक्त एनपीएम अखंडता द्वारा हस्ताक्षरित है, लेकिन आधार मामला सरल है: प्रकाशक एक बार डाइजेस्ट की गणना करता है, इसे लॉकफ़ाइल में रिकॉर्ड करता है, और उपभोक्ता पक्ष के टूल सत्यापित करते हैं कि डाउनलोड किए गए बाइट्स मेल खाते हैं।
पैकेज अखंडता एन्कोडिंग भिन्न होती है; यहां केवल इस कैलकुलेटर के समर्थित SHA आउटपुट का दावा किया गया है
समान एल्गोरिदम के माध्यम से समान बाइट्स हमेशा एक ही डाइजेस्ट उत्पन्न करते हैं, भले ही बाइट्स कहां से आए हों। एक डेवलपर की कमिट का स्थानीय निर्माण उसी SHA-256 को CI/CD सिस्टम के रूप में उत्पन्न करता है जो समान रिपॉजिटरी से समान संशोधन की जाँच करता है। इस प्रतिलिपि प्रस्तुत करने योग्यता के कारण सामग्री संबोधन कार्य करता है: आप वितरण तंत्र पर भरोसा किए बिना किसी कलाकृति को सत्यापित कर सकते हैं। डाइजेस्ट एक क्रिप्टोग्राफ़िक प्रतिबद्धता बन जाता है: एक बाइट बदलने से भी यह अमान्य हो जाता है।
डाइजेस्ट को अलग से वितरित करना (कलाकृतियों को वितरित करने से पहले) उड़ान में संशोधन से बचाता है। रिलीज़ से पहले प्रकाशित एक वेब पेज "expect SHA-256:abc..." प्रदर्शित कर सकता है और फिर उपयोगकर्ता इसके विरुद्ध डाउनलोड सत्यापित कर सकते हैं। सार्वजनिक रिपॉजिटरी में प्रकाशित एक गिट कमिट बाइट्स के प्रति एक प्रतिबद्धता है; डाइजेस्ट इसे साबित करता है।
कार्यान्वित उदाहरण - डाइजेस्ट करने के लिए बाइट्स से एक ब्लॉब का अनुसरण करते हुए उस नाम का उपयोग करना जो टूल इसके लिए उपयोग करता है
अलग-अलग प्रणालियाँ अपने डाइजेस्ट को अलग-अलग तरीके से एन्कोड करती हैं। Git डिफ़ॉल्ट रूप से लोअरकेस हेक्साडेसिमल (40 या 64 हेक्स वर्ण) का उपयोग करता है। Docker हेक्स के बाद `sha256:` प्रारूप का उपयोग करता है। एनपीएम और गो अखंडता क्षेत्रों में Base64 का उपयोग करते हैं। बाइट्स समान हैं; केवल प्रतिनिधित्व भिन्न है। "एबीसी" पर एक SHA-256 डाइजेस्ट हमेशा एक ही 256 bits होता है, लेकिन आप इसे 64-कैरेक्टर हेक्स स्ट्रिंग, 44-कैरेक्टर Base64 स्ट्रिंग या `sha256:` जैसे लेबल के बाद देख सकते हैं। एन्कोडिंग के बीच रूपांतरण हानिरहित है; प्रत्येक प्रतिनिधित्व में डाइजेस्ट का मान समान है।
सभी टूलों में डाइजेस्ट की तुलना करते समय एन्कोडिंग को समझना मायने रखता है। यदि Git एक हेक्स डाइजेस्ट प्रिंट करता है और एक टूल Base64 दिखाता है, तो आपको यह सत्यापित करने के लिए कि वे मेल खाते हैं, एक प्रतिनिधित्व को दूसरे में परिवर्तित करना होगा। ToolAcre का SHA हैश कैलकुलेटर प्रत्येक डाइजेस्ट के लिए हेक्स और Base64 दोनों प्रदर्शित करता है, जिससे अन्य प्रणालियों के साथ कन्वर्ट करना या क्रॉस-रेफरेंस करना आसान हो जाता है।
इसमें क्या शामिल नहीं है - प्रत्येक टूल द्वारा उपयोग की जाने वाली विशिष्ट एन्कोडिंग (हेक्स बनाम Base64), जिसे एक अलग पोस्ट में कवर किया गया है
सामग्री का पता क्रिप्टोग्राफ़ी के लिए विशिष्ट नहीं है, हालाँकि क्रिप्टोग्राफ़िक हैश इसे सुरक्षित बनाते हैं। CRC32 चेकसम भी डेटा को सामग्री-पता देता है, लेकिन CRC32 टकराव आम हैं और टकराव निर्मित किए जा सकते हैं; यह भंडार SHA-256 को टूटे हुए के रूप में चिह्नित नहीं करता है, जबकि CRC32 को प्रतिकूल अखंडता आदिम के रूप में पेश नहीं किया जाता है। सुरक्षा के लिए हैश एल्गोरिदम का चुनाव मायने रखता है: SHA-256 उन प्रणालियों के लिए आधुनिक मानक है जिन्हें विरोधियों के खिलाफ अखंडता सुरक्षा की आवश्यकता होती है। SHA-1 केवल विरासत है (Git और अन्य दूर जा रहे हैं)। नामकरण योजना के रूप में सामग्री पते को चुनने से सही एल्गोरिदम चुनना एक अलग निर्णय है।
क्रिप्टोग्राफ़िक हैश के साथ संयुक्त सामग्री संबोधन आधुनिक सॉफ़्टवेयर में आपूर्ति-श्रृंखला अखंडता की नींव है। आपके द्वारा इंस्टॉल किए गए प्रत्येक पैकेज, आपके द्वारा चलाए गए प्रत्येक कंटेनर और आपके द्वारा चेक किए गए प्रत्येक कमिट को मूल प्रकाशक द्वारा इच्छित बाइट्स के रूप में सत्यापित किया जा सकता है, सुरक्षित ट्रांसफर पर भरोसा किए बिना (हालांकि सुरक्षित ट्रांसफर अभी भी अच्छा अभ्यास है)।
टेकवे: हैश पहचान है - ToolAcre SHA हैश कैलकुलेटर आपको उसी डाइजेस्ट की गणना करने देता है जिस पर ये सिस्टम भरोसा करते हैं
सामग्री का पता एन्कोडिंग, भंडारण स्थान या स्थानांतरण तंत्र से स्वतंत्र है। समान बाइट्स समान डाइजेस्ट उत्पन्न करते हैं, चाहे उन्हें स्थानीय रूप से, CDN में, रजिस्ट्री में संग्रहीत किया गया हो या HTTP या सुरक्षित HTTPS पर प्रसारित किया गया हो। डाइजेस्ट बाइट्स के लिए एक क्रिप्टोग्राफ़िक प्रतिबद्धता है, और इसे सत्यापित करने के लिए केवल बाइट्स और एल्गोरिदम की आवश्यकता होती है, किसी बाहरी सेवा की नहीं। यही कारण है कि कंटेंट एड्रेसिंग ऑफ़लाइन सत्यापन को सक्षम बनाता है: आप एक अविश्वसनीय चैनल पर एक फ़ाइल डाउनलोड कर सकते हैं, डाइजेस्ट की जांच कर सकते हैं और जान सकते हैं कि बाइट्स प्रामाणिक हैं या नहीं।
ToolAcre SHA हैश कैलकुलेटर आपको उसी डाइजेस्ट की गणना करने देता है जिस पर ये सिस्टम भरोसा करते हैं। एक स्ट्रिंग चिपकाएँ या फ़ाइल देखें, कैलकुलेटर चलाएँ और SHA-256, SHA-384 और SHA-512 डाइजेस्ट देखें जो Docker, गिट, एनपीएम और अन्य टूल आंतरिक रूप से उपयोग करते हैं। बाइट्स को संशोधित नहीं किया गया है यह सत्यापित करने के लिए मूल स्रोत से अपने गणना किए गए डाइजेस्ट की तुलना करें। कैलकुलेटर आपके द्वारा पेस्ट किए गए UTF-8 टेक्स्ट को हैश कर देता है; इसमें फ़ाइलें या कुंजी सामग्री हैश नहीं है, इसलिए यह क्या हैश (पाठ इनपुट) कर सकता है और क्या नहीं (बाइनरी फ़ाइलें, उनके एन्कोडेड रूपों में क्रिप्टोग्राफ़िक कुंजियाँ) के बीच की सीमा स्पष्ट और प्रलेखित है।