Linux मध्ये checksum ने download कसे पडताळावे

दोन मिनिटांत checksum वापरून download पडताळा

checksum वापरून download पडताळण्यासाठी, मिळालेल्या file वर hash काढा आणि publisher ने दिलेल्या hash शी तो hash जुळतो का हे tool कडून तपासा. sha256sum ही दोन्ही कामे करते: स्वतंत्रपणे वापरल्यास ती digest दाखवते आणि -c सह वापरल्यास ती digest ची list वाचून कोणत्या files जुळतात हे सांगते. या मार्गदर्शिकेत तुम्ही तयार केलेल्या file वर संपूर्ण प्रक्रिया चालवली जाईल. त्यानंतर ती file जाणीवपूर्वक बदलली जाईल, त्यामुळे failure प्रत्यक्ष पाहता येईल.

संपूर्ण प्रक्रियेत एक गोष्ट लक्षात ठेवा. checksum तुम्ही ज्या bytes जवळ ठेवता त्या bytes मुळेच digest तयार झाला आहे का हे सांगतो; तो digest कोणी तयार केला हे मात्र सांगत नाही. त्या दुसऱ्या प्रश्नासाठी signature आणि तुमचा विश्वास असलेली key आवश्यक असते. या मार्गदर्शिकेच्या शेवटच्या भागात checksum आणि signature यांच्यातील नेमकी सीमा दाखवली आहे.

सरावासाठी फाइल तयार करा

ही प्रक्रिया scratch directory मध्ये करा, जेणेकरून यातील कोणत्याही कृतीचा उर्वरित system वर परिणाम होणार नाही. खालील प्रत्येक command GNU coreutils मधून येतो. Ubuntu किंवा Debian server वर उपलब्ध असलेल्या मूलभूत command संचाचा तो भाग आहे. त्यामुळे काहीही install करण्याची गरज नाही.

mkdir -p ~/checksum-demo
cd ~/checksum-demo
printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum payload.txt

तुम्हाला एक ओळ मिळते: 64 hexadecimal characters, त्यानंतर दोन spaces आणि मग file name. हे 64 characters त्या file चे digest आहेत. तो command पुन्हा चालवला तरी ओळ तशीच राहते, कारण hashing deterministic असते: समान input मुळे नेहमी समान output मिळतो. File मधील एक character बदलून command पुन्हा चालवला, तरी digest मध्ये फक्त थोडासा बदल होत नाही. तो पूर्णपणे वेगळा दिसतो, कारण input मधील एक bit बदलल्यावर output मधील सुमारे निम्मे bits बदलतात. या गुणधर्मामुळे 64-character string ही 4 GB image साठी वापरता येणारी प्रतिनिधी value ठरते.

SHA256SUMS फाइल जतन करा आणि तिची तपासणी करा

स्क्रीनवर दिसणारा digest एका दिवसानंतर उपयोगी राहत नाही. तो फाइलमध्ये लिहा. sha256sum स्वतः ज्या स्वरूपात लिहिते तेच स्वरूप वापरा, जेणेकरून हे साधन तो नंतर पुन्हा वाचू शकेल.

sha256sum payload.txt > SHA256SUMS
cat SHA256SUMS
sha256sum -c SHA256SUMS

sha256sum -c यादीतील प्रत्येक ओळ वाचते, त्या ओळीत नमूद केलेल्या फाइलचा hash तयार करते आणि दोन्ही digest ची तुलना करते. यशस्वी तपासणीत प्रत्येक फाइलसाठी एक ओळ दिसते:

payload.txt: OK

Exit status देखील तपासा, कारण script त्यातून निकाल वाचते; मजकूर कधीच वाचत नाही. यशस्वी तपासणीनंतर echo $?, 0 दाखवते. SHA256SUMS हे नाव अनिवार्य नियम नसून प्रचलित पद्धत आहे. मात्र distributions आणि बहुतेक release pages हेच नाव वापरतात. त्यामुळे तुम्हीही तेच नाव वापरा. मग फाइल न उघडताही पुढील व्यक्तीला तिच्यात काय आहे हे समजते.

एक byte बदलून तपासणी अयशस्वी होताना पाहा

आता फाइल मुद्दाम खराब करा. यामुळे offset 5 वर एकच byte लिहिला जातो आणि उर्वरित सर्व काही तसेच राहते. त्यामुळे फाइलची लांबी आणि नाव बदलत नाही.

printf 'X' | dd of=payload.txt bs=1 seek=5 conv=notrunc status=none
cat payload.txt
sha256sum -c SHA256SUMS

conv=notrunc हा महत्त्वाचा flag आहे. तो नसल्यास, dd जिथे लेखन थांबवते तिथे फाइल truncate करते. त्यामुळे तुम्ही अधिक स्पष्ट प्रकारच्या नुकसानीची तपासणी करत असता. आता तपासणी असे output देते:

payload.txt: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

echo $? हे 1 print करते. FAILED याचा अर्थ फाइल वाचली गेली, पण तिचा digest यादीतील digest शी जुळला नाही. मूळ bytes पुन्हा लिहा आणि तपासणी OK वर परतते याची खात्री करा:

printf 'the payload of a totally ordinary download\n' > payload.txt
sha256sum -c SHA256SUMS

हीच पूर्ण पद्धत आहे. फाइलमध्ये कुठेही फक्त एका byte चा फरक असला तरी FAILED निर्माण होते. कनेक्शन तुटल्यामुळे मध्येच थांबलेले download, कालची build देणारा mirror, network traffic मध्ये फाइल बदलणारा proxy किंवा चुकीचा block परत करणारी disk — या सर्वांची नोंद त्याच ओळीत होते.

सूचीमध्ये तुम्ही डाउनलोड न केलेल्या फाइलचे नाव असल्यास

वितरणातील खरी SHA256SUMS फाइल प्रकल्पाने रिलीज केलेल्या प्रत्येक image ची नोंद करते आणि तुम्ही त्यांपैकी एक image डाउनलोड केलेली असते. येथे तीच परिस्थिती पुन्हा तयार करा.

printf 'a second file\n' > notes.txt
sha256sum payload.txt notes.txt > SHA256SUMS.all
rm notes.txt
sha256sum -c SHA256SUMS.all

payload.txt: OK
sha256sum: notes.txt: No such file or directory
notes.txt: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read

FAILED open or read हे FAILED पेक्षा वेगळे अपयश आहे. या दोन्हींची गल्लत केल्यास वेळ वाया जातो. FAILED म्हणजे bytes चुकीचे आहेत. FAILED open or read म्हणजे sha256sum ला फाइल मिळालीच नाही, त्यामुळे कोणतीही तुलना झाली नाही. प्रत्यक्ष डाउनलोडमध्ये याचे नेहमीचे कारण working directory असते, कारण सूचीतील नावे तुम्ही command ज्या ठिकाणाहून चालवता त्या ठिकाणाच्या संदर्भात असतात. फाइल असलेल्या directory मध्ये जा आणि command पुन्हा चालवा. तुमच्याकडे प्रत्यक्षात असलेल्या फाइलचीच तपासणी करण्यासाठी पुढील पर्याय वापरा:

sha256sum --ignore-missing -c SHA256SUMS.all

यामुळे payload.txt: OK छापले जाते आणि प्रक्रिया 0 या exit status सह बंद होते. सूचीतील एकही नाव उपलब्ध नसल्यास --ignore-missing शून्य फाइल्सवर शांतपणे यशस्वी होत नाही. ते no file was verified कळवते आणि non-zero exit status सह बंद होते. हेच अपेक्षित वर्तन आहे, कारण कोणतीही तपासणी न केलेली यशस्वी प्रक्रिया असे अपयश लपवेल, ज्याची तुम्हाला कधीच जाणीव होणार नाही.

दृष्टीने न वाचता प्रकाशित digest पेस्ट करा

64 hexadecimal अक्षरांची दृष्टीने तुलना करणे ही सवय खरोखर अपयशी ठरण्याची जागा आहे. लोक पहिली चार अक्षरे आणि शेवटची चार अक्षरे तपासून ती जुळतात असे मानतात. नेमकी हीच तुलना ठरवून केलेला हल्लेखोर गृहीत धरतो. त्याऐवजी तुलना tool कडून करून घ्या. publisher कडून कॉपी केलेल्या digest वर EXPECTED सेट करा. त्यासाठी EXPECTED= नंतर पेस्ट केलेली value द्या. त्यानंतर -c ला अपेक्षित असलेली एकच ओळ तयार करा:

printf '%s  %s\n' "$EXPECTED" payload.txt > payload.sha256
cat payload.sha256
sha256sum -c payload.sha256

digest आणि file name यांच्यामध्ये दोन spaces असतात. म्हणून format string मध्ये दोन spaces आहेत. sha256sum लिहिते तोच हा format आहे आणि -c तोच format parse करते. digest आणि त्याशिवाय दुसरे काहीही नसलेली file ही checksum line नसते. त्यामुळे check संपूर्ण file no properly formatted checksum lines found सह नाकारते; तुम्हाला कोणती file अभिप्रेत आहे याचा अंदाज ती लावत नाही. काही projects त्याऐवजी BSD tagged style प्रकाशित करतात: SHA256 (payload.txt) = नंतर digest. GNU coreutils ही रचना sha256sum --tag payload.txt सह लिहिते आणि -c सह पुन्हा वाचते. त्यामुळे जतन करण्यासाठी दोन्हीपैकी कोणतीही रचना वापरता येते.

check अनपेक्षितरीत्या वागत असेल, तर cat -A SHA256SUMS सह list स्वतः तपासा. ते प्रत्येक ओळीच्या शेवटी $ दर्शवते आणि अन्यथा दिसणार नाहीत अशी characters दाखवते. ^M$ ने संपणाऱ्या ओळीत Windows editor मधून आलेला carriage return असतो. GNU sha256sum त्या शेवटच्या character कडे दुर्लक्ष करते आणि तरीही OK छापते. त्यामुळे CRLF list ही check अपयशी होण्याचे कारण नाही. मात्र coreutils बाहेरील tools त्याबाबत कमी सहनशील असू शकतात. तुम्ही ठेवलेली copy tr -d '\r' < SHA256SUMS > SHA256SUMS.clean सह normalize करा.

Checksum काय सिद्ध करतो आणि काय सिद्ध करत नाही?

Checksum एक गोष्ट सिद्ध करतो: तुमच्या disk वरील bytes हे प्रकाशित digest तयार करणारेच bytes आहेत. त्यामुळे अपघाती नुकसान पूर्णपणे ओळखता येते. Download mirror वरील file बदलणाऱ्या, पण digest प्रकाशित करणाऱ्या page मध्ये बदल करू न शकणाऱ्या निष्काळजी हल्लेखोराविरुद्धही हे लागू होते.

तो file कोणी तयार केला हे सिद्ध करत नाही. Digest हा bytes विषयीचा तथ्यात्मक पुरावा आहे; तो व्यक्तींविषयीचा पुरावा नाही. एकाच page वरून file आणि digest दोन्ही दिले जात असतील, तर एक बदलू शकणारी व्यक्ती दुसरेही बदलू शकते. अशा वेळी तुमची OK line फक्त mirror स्वतःशी सहमत असल्याचे दाखवते. त्यामुळे checksums काढण्याचा महत्त्वाचा नियम असा आहे: file जिथून घेतली, त्यापेक्षा वेगळ्या ठिकाणाहून digest घ्या. उदाहरणार्थ, image mirror किंवा torrent वरून घेतली असेल, तर project's own domain वरून TLS (transport layer security) द्वारे digest घ्या. आता हल्लेखोराला एका ठिकाणाऐवजी दोन ठिकाणांवर नियंत्रण मिळवावे लागेल. मात्र, हे verified bytes तुम्ही चालवल्यानंतर काय करतील याबद्दल checksum काहीही सांगत नाही. तुमच्या वतीने execute होणाऱ्या कोणत्याही गोष्टीबाबत हा स्वतंत्रपणे विचार करण्यासारखा प्रश्न आहे. यात install script पासून तुमच्या agent च्या permissions सह चालणाऱ्या dsh plugin पर्यंत सर्वांचा समावेश होतो.

Algorithm देखील महत्त्वाचा आहे. SHA-256 (secure hash algorithm, 256-bit output) साठी August 2026 पर्यंत कोणतीही ज्ञात collision नाही. त्यामुळे publishers तो वापरतात. MD5 (message digest 5) आणि SHA-1 विश्वासार्ह ठरत नाहीत. समान MD5 digest असलेल्या दोन वेगळ्या files तयार करणे 2004 पासून शक्य आहे. Chosen-prefix SHA-1 collision 2020 मध्ये प्रकाशित करण्यात आली. An MD5SUMS file truncated download ओळखू शकते, कारण random corruption ही crafted collision नसते. तुम्हाला फसवण्याचा प्रयत्न करणाऱ्या व्यक्तीला ते थांबवू शकत नाही. Project दोन्ही प्रकाशित करत असल्यास, SHA-256 line वापरा.

स्वाक्षऱ्यांची भूमिका

डायजेस्टमुळे उरलेली पडताळणीची त्रुटी स्वाक्षरी भरून काढते. प्रकाशक private key ने डायजेस्ट फाइलवर स्वाक्षरी करतो आणि तुम्ही ती त्यांच्या public key ने तपासता: gpg --verify SHA256SUMS.asc SHA256SUMS. ही पडताळणी यशस्वी झाल्यास, डायजेस्टची यादी ती key धारण करणाऱ्या व्यक्ती किंवा संस्थेकडून आली आहे. त्यानंतर sha256sum -c SHA256SUMS तुमच्या disk वरील फाइलला त्या यादीशी जोडते आणि ही साखळी key पासून थेट bytes पर्यंत जाते.

कमकुवत दुवा key कडे सरकतो. फाइल दिलेल्याच पेजवरून key मिळवल्यास, हल्लेखोराला दोन्ही भाग पुन्हा बदलण्याची संधी मिळते. GnuPG याबाबत स्पष्ट असते. पहिल्या पडताळणीत Good signature आणि WARNING: This key is not certified with a trusted signature! दिसतात. Good signature याचा अर्थ गणितीय पडताळणी यशस्वी झाली आहे. मात्र, ती key तुमच्या अपेक्षित project चीच आहे असा त्याचा अर्थ होत नाही. Fingerprint दुसऱ्या स्रोताकडून मिळवा. उदाहरणार्थ, वेगळ्या domain वरील project चे documentation किंवा key आधीच समाविष्ट असलेले distribution package वापरा. शेवटची आठ characters पाहण्याऐवजी संपूर्ण fingerprint ची तुलना करा. यासाठी SSH private key ला द्यावी लागणारी तीच काळजी आवश्यक आहे. कारणही तेच आहे: key हा trust चा निर्णय असतो आणि त्यानंतरची संपूर्ण साखळी त्यावर अवलंबून असते.

Reproducible builds ही कल्पना आणखी पुढे नेतात. प्रकाशित डायजेस्टमुळे तुम्ही एका machine ने तयार केलेल्या binary शी जोडले जाता. एखाद्या project चे build reproducible असल्यास, कोणतीही व्यक्ती तोच source compile करून byte-identical output मिळवू शकते. त्यामुळे independent builders प्रकाशित डायजेस्टची पुष्टी करू शकतात; एका server च्या दाव्यावर विश्वास ठेवण्याची गरज राहत नाही. Automated pipelines आणि machine-written patches द्वारे अधिक code उपलब्ध होत असल्याने याचे महत्त्व दरवर्षी वाढत आहे. Build मध्ये काय स्वीकारायचे हा policy चा प्रश्न आहे. AI-assisted code साठीच्या open source policies supply chain च्या दुसऱ्या टोकापासून याच प्रक्रियेवर काम करतात.

तुमचा package manager हे काम आधीच करतो

Debian आणि Ubuntu वर, apt प्रत्येक install वेळी ही प्रक्रिया कोणतीही अतिरिक्त सूचना न मागता चालवते. Package index मध्ये प्रत्येक .deb file साठी SHA-256 digest असतो. Release file मध्ये त्या index files चे digests असतात. InRelease मध्ये Release वरील signature असते. ही signature /usr/share/keyrings आणि /etc/apt/trusted.gpg.d मधील keys विरुद्ध तपासली जाते. ही साखळी तुटल्यास apt ते स्पष्टपणे दाखवतो: तृतीय-पक्ष repository ची key उपलब्ध नसल्यास The following signatures couldn't be verified because the public key is not available: NO_PUBKEY, किंवा तुम्ही मिळवलेला index signed Release शी जुळत नसल्यास Hash Sum mismatch. दुसऱ्या परिस्थितीचा अर्थ सहसा caching proxy ने जुनी file दिली आहे किंवा mirror चे synchronization सुरू असताना ती file मिळाली आहे.

प्रकल्पाच्या home page वर curl मधून थेट shell मध्ये script pipe करण्यास सांगितले असल्यास, त्याची तुलना या मानकाशी करा. या पद्धतीत bytes ची कोणतीही पडताळणी होत नाही आणि तुम्हाला ते दिसतही नाहीत. Server एखाद्या script ला एक content आणि browser ला दुसरे content देऊ शकतो. नंतर तपासण्यासाठी तुमच्याकडे त्याची copyही राहत नाही. curl -fsSL <url> -o install.sh वापरून ती file download करा, तिचा hash काढा, less वापरून ती वाचा आणि त्यानंतरच चालवा. ही सवय अंगीकारण्यासाठी सुमारे वीस सेकंद लागतात. कोणतेही इतर software install करण्यापूर्वी, अगदी नवीन VPS वर सुरुवातीच्या दहा मिनिटांत हीच सवय सुरू करणे उपयुक्त ठरते.

हाताने स्थापित केलेल्या घटकांसाठी digest ची यादी ठेवा

apt ने स्थापित केलेल्या packages ची नोंद ठेवली जाते. तुम्ही /usr/local/bin मध्ये कॉपी केलेल्या binary ची नोंद ठेवली जात नाही आणि system वरील कोणतीही प्रक्रिया तिच्यावर लक्ष ठेवत नाही. digest ची यादी ठेवल्यास ती मागणीनुसार तपासता येते:

printf 'a second file\n' > notes.txt
sha256sum *.txt > inventory.sha256
sha256sum -c --quiet inventory.sha256

प्रत्येक file जुळत असल्यास --quiet काहीही print करत नाही. काही file जुळत नसल्यास ते फक्त अपयशी ठरलेल्या lines print करते. त्यामुळे शांत output म्हणजे तपासणी यशस्वी झाली आहे आणि echo $? हे 0 द्वारे त्याची पुष्टी करते. Scheduled job मध्ये वापरण्यासाठी हेच स्वरूप योग्य आहे. --status आणखी पुढे जाऊन कोणताही output print करत नाही; फक्त exit status उपलब्ध राहतो. sha256sum /usr/local/bin/* > ~/local-bin.sha256 वापरून हाच pattern प्रत्यक्ष files वर लागू केल्यास baseline तयार होते. Paths तुम्ही ज्या स्वरूपात टाइप करता त्याच स्वरूपात यादीत साठवले जातात. त्यामुळे absolute paths वापरल्यास कोणत्याही directory मधून तपासणी करता येते.

त्या baseline चे महत्त्व नेमके समजून घ्या. ते बदललेली file शोधते. पण ज्याला आधीच root access मिळाले आहे अशा attacker ला ते शोधू शकत नाही, कारण त्या attacker कडे binary प्रमाणेच inventory.sha256 पुन्हा लिहिण्याची क्षमता असते. यादीचा अर्थपूर्ण वापर करायचा असल्यास ती machine च्या बाहेर ठेवा. तुम्ही प्रत्यक्षात VPS वर किती विश्वास ठेवता आणि त्याखालील disk पर्यंत आणखी कोण पोहोचू शकते, या व्यापक प्रश्नाचाही तो एक भाग आहे: तुम्ही प्रत्यक्षात VPS वर किती विश्वास ठेवता.

FAQ

जुळणारा checksum म्हणजे download सुरक्षित आहे असे समजावे का?

नाही. याचा अर्थ तुमच्याकडील bytes आणि तुम्ही ज्यांच्याशी तुलना केली त्या digest मधील bytes जुळतात. जर digest प्रकाशित करणाऱ्या page वर attacker चे नियंत्रण असेल, तर तो स्वतःच्या file चा digest प्रकाशित करेल आणि तुमची तपासणी OK दाखवेल. जुळणारा digest ही consistency ची खात्री असते. सुरक्षिततेची खात्री मिळवण्यासाठी वेगळ्या source कडून मिळवलेल्या key विरुद्ध signature verify करणे आवश्यक असते. त्यानंतरच त्या विश्वासामुळे digest वर विश्वास ठेवता येतो.

sha256sum -c FAILED open or read का दाखवते?

कारण तिने file वाचलेली नाही. त्याच्या अगदी वरच्या स्वतंत्र line मध्ये No such file or directory आणि शोधलेले नाव दिलेले असते. SHA256SUMS file मधील नावे तुम्ही command ज्या directory मधून चालवता त्या directory च्या तुलनेत relative असतात. त्यामुळे download असलेल्या directory मध्ये जा आणि command पुन्हा चालवा. List मध्ये तुम्ही download न केलेल्या files ची नावेही असल्यास --ignore-missing जोडा. कोणत्याही open or read शिवाय साधे FAILED दिसणे ही उलट परिस्थिती आहे: file वाचली गेली, पण तिचा digest जुळला नाही.

Download पडताळण्यासाठी MD5 पुरेसे आहे का?

अपघाती नुकसानासाठी होय. अपूर्ण transfer किंवा disk वरील खराब block मुळे योगायोगाने जुळणारा MD5 digest तयार होत नाही. Attacker विरुद्ध नाही. समान MD5 digest असलेल्या दोन वेगवेगळ्या files 2004 पासून तयार करता येतात. 2020 मध्ये SHA-1 देखील chosen-prefix collision मुळे असुरक्षित ठरले. Project ने SHA-256 आणि MD5 दोन्ही दिले असल्यास SHA-256 line वापरा. फक्त MD5 देणारा project जुनी release process वापरत असल्याचे संकेत म्हणून घ्या.

sha256sum -c आणि gpg --verify यांच्यात काय फरक आहे?

sha256sum -c एखादी file digest शी जुळते हे सिद्ध करते. gpg --verify एखादी digest file विशिष्ट private key धारकाने sign केली आहे हे सिद्ध करते. ते वेगवेगळ्या प्रश्नांची उत्तरे देतात. Project ने दोन्ही उपलब्ध करून दिल्यास दोन्ही चालवा. Signature मुळे digest list वर विश्वास ठेवता येतो. त्यानंतर digest list मुळे downloaded file वर विश्वास ठेवता येतो.

Web page वर छापलेल्या digest शी एक file कशी तपासावी?

Characters डोळ्यांनी जुळवू नका. Digest आणि file name एकाच line वर, दोन spaces ने वेगळे करून save करा. त्यानंतर त्या file विरुद्ध sha256sum -c चालवा आणि त्याने दाखवलेले OK किंवा FAILED वाचा. printf '%s %s\n' वापरून line तयार केल्यास formatting मधील चुका टाळता येतात. अशा चुका झाल्यास sha256sum file नाकारून no properly formatted checksum lines found दाखवते.