Linux मध्ये checksum ने डाउनलोड कसे तपासावे

दोन मिनिटांत checksum वापरून डाउनलोडची पडताळणी करा

checksum वापरून डाउनलोडची पडताळणी करण्यासाठी, मिळालेल्या फाइलचा hash काढा आणि publisher ने दिलेल्या hash शी तो hash जुळतो का हे एखाद्या साधनाद्वारे तपासा. sha256sum ही दोन्ही कामे करते: स्वतंत्रपणे वापरल्यास ती digest दाखवते, आणि -c सह वापरल्यास ती digest ची सूची वाचते आणि कोणत्या फाइल्स जुळतात ते सांगते. या मार्गदर्शकात तुम्ही तयार केलेल्या फाइलवर संपूर्ण प्रक्रिया चालवली जाईल. त्यानंतर ती फाइल मुद्दाम बदलली जाईल, त्यामुळे अपयश प्रत्यक्ष दिसेल.

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

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

काम करण्यासाठी तात्पुरती directory वापरा, जेणेकरून येथे केलेल्या कोणत्याही कृतीचा उर्वरित system वर परिणाम होणार नाही. खालील प्रत्येक command GNU coreutils मधून येतो. हा मूलभूत command संच कोणत्याही Ubuntu किंवा Debian server वर उपलब्ध असतो. त्यामुळे काहीही 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 साठी वापरता येणारी प्रतिनिधी खूण ठरते.

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

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

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

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

payload.txt: OK

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

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

आता फाइल जाणीवपूर्वक खराब करा. ही कमांड offset 5 वरील एकच बाइट लिहिते आणि इतर सर्व मजकूर तसाच ठेवते. त्यामुळे फाइलची लांबी आणि नाव कायम राहते.

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 करते. त्यामुळे तुम्ही अधिक स्पष्ट स्वरूपाच्या खराबीची पडताळणी करत असता. आता पडताळणी पुढीलप्रमाणे दाखवते:

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

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

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

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

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

वितरणातील वास्तविक SHA256SUMS फाइलमध्ये प्रकल्पाने release केलेल्या प्रत्येक 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 पेक्षा वेगळे failure आहे. या दोन्हींची गल्लत केल्यास वेळ वाया जातो. FAILED म्हणजे bytes चुकीचे आहेत. FAILED open or read म्हणजे sha256sum ला फाइल मिळालीच नाही, त्यामुळे कोणतीही तुलना झाली नाही. प्रत्यक्ष download मध्ये याचे सामान्य कारण working directory असते, कारण सूचीतील नावे तुम्ही command कुठून चालवता त्या directory च्या सापेक्ष असतात. फाइल असलेल्या directory मध्ये जा आणि command पुन्हा चालवा. तुमच्याकडे प्रत्यक्षात असलेल्या फाइल्सच तपासण्यासाठी ही विनंती करा:

sha256sum --ignore-missing -c SHA256SUMS.all

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

डोळ्यांनी न वाचता प्रकाशित digest पेस्ट करा

64 hexadecimal अक्षरांची डोळ्यांनी तुलना करताना ही सवय खरोखरच अपयशी ठरते. लोक पहिले चार अक्षर आणि शेवटचे चार अक्षर तपासून त्यांना जुळणारे मानतात. नेमकी हीच तुलना एखादा निर्धार केलेला हल्लेखोर गृहीत धरतो. त्याऐवजी तुलना tool कडून करून घ्या. प्रकाशकाकडून कॉपी केलेला 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 मानली जात नाही. त्यामुळे कोणती file अभिप्रेत आहे याचा अंदाज न लावता check no properly formatted checksum lines found सह संपूर्ण file नाकारतो. काही projects BSD tagged style प्रकाशित करतात. त्यात SHA256 (payload.txt) = नंतर digest असतो. GNU coreutils ही रचना sha256sum --tag payload.txt सह लिहिते आणि -c सह पुन्हा वाचते. त्यामुळे save करण्यासाठी दोन्ही रचना योग्य आहेत.

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

चेकसम काय सिद्ध करते आणि काय सिद्ध करत नाही?

चेकसम एकच गोष्ट सिद्ध करते: तुमच्या डिस्कवरील bytes हे प्रकाशित digest तयार करणारेच bytes आहेत. त्यामुळे अपघाती नुकसान पूर्णपणे शोधता येते. तसेच, download mirror वरील फाइल बदलणारा पण digest प्रकाशित करणारे पृष्ठ बदलू न शकणारा निष्काळजी हल्लेखोरही यातून पकडला जातो.

यातून लेखकत्वाबद्दल काहीही सिद्ध होत नाही. Digest हा bytes विषयीचा तथ्यात्मक पुरावा आहे; तो कोणत्या व्यक्तींविषयीचा पुरावा नाही. एकाच पृष्ठावरून फाइल आणि digest दोन्ही उपलब्ध होत असतील, तर त्यापैकी एक बदलू शकणारी व्यक्ती दुसरेही बदलू शकते. अशा वेळी तुमची OK ओळ केवळ mirror स्वतःशी सहमत असल्याचे दर्शवते. म्हणूनच चेकसम काढणे उपयुक्त ठरणारा नियम असा आहे: फाइल जिथून घेतली, त्यापेक्षा वेगळ्या ठिकाणाहून digest घ्या. उदाहरणार्थ, image mirror किंवा torrent वरून घेतली असेल, तर प्रकल्पाच्या स्वतःच्या domain वरून TLS (transport layer security) द्वारे digest घ्या. आता हल्लेखोराला एका ठिकाणाऐवजी दोन ठिकाणांवर नियंत्रण मिळवावे लागेल.

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 मध्ये प्रकाशित झाला. एखादी MD5SUMS file अपूर्ण download झाल्याचे अद्याप शोधते, कारण random corruption ही crafted collision नसते. मात्र, तुम्हाला फसवण्याचा प्रयत्न करणाऱ्या व्यक्तीला ती थांबवू शकत नाही. प्रकल्पाने दोन्ही प्रकाशित केले असतील, तर SHA-256 ओळ वापरा.

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

डायजेस्टमुळे उरलेली दरी स्वाक्षरी भरून काढते. प्रकाशक 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 वापरा. त्यानंतर शेवटच्या आठ अक्षरांऐवजी पूर्ण fingerprint ची तुलना करा. हे SSH private key साठी आवश्यक असलेल्या त्याच काळजीसारखे आहे. कारण एकच आहे: key हा विश्वासाचा निर्णय असतो आणि त्यानंतरच्या प्रत्येक घटकाचा आधार त्यावर असतो.

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

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

Debian आणि Ubuntu वर, प्रत्येक install वेळी apt ही chain आपोआप चालवतो. 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 विरुद्ध तपासली जाते. ही chain कुठे तुटली तर apt ते स्पष्टपणे सांगतो: third-party repository ची key नसल्यास The following signatures couldn't be verified because the public key is not available: NO_PUBKEY, किंवा तुम्ही fetch केलेला index signed Release शी जुळत नसल्यास Hash Sum mismatch. याचा अर्थ सहसा caching proxy ने जुनी file दिली आहे किंवा mirror चे sync काम सुरू असताना तुम्ही ती file मिळवली आहे.

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

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

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

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

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

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

FAQ

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

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

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

कारण त्याने file वाचलीच नाही. त्याच्या अगदी वरच्या स्वतंत्र line मध्ये त्याने शोधलेले नाव असलेले No such file or directory दिलेले असते. SHA256SUMS file मधील नावे तुम्ही command ज्या directory मध्ये चालवता त्या directory च्या संदर्भातील असतात. त्यामुळे 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 मुळे download केलेली file विश्वासार्ह ठरते.

web page वर छापलेल्या digest विरुद्ध एक file कशी तपासावी?

अक्षरे पाहून तुलना करू नका. 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 दाखवते.