Linux-এ checksum দিয়ে download যাচাই করার নিয়ম

দুই মিনিটে checksum দিয়ে একটি download যাচাই করুন

checksum দিয়ে একটি download যাচাই করতে, আপনার পাওয়া file-টির hash তৈরি করুন এবং একটি tool-কে সেই hash publisher-এর প্রকাশ করা hash-এর সঙ্গে তুলনা করতে দিন। sha256sum কাজটির উভয় ধাপই সম্পন্ন করে: একা এটি একটি digest দেখায়, আর -c-সহ এটি digest-এর একটি তালিকা পড়ে এবং কোন file মিলে তা জানায়। এই guide-এ আপনি তৈরি করা একটি file নিয়ে পুরো প্রক্রিয়াটি চালাবেন। এরপর ইচ্ছাকৃতভাবে file-টি পরিবর্তন করবেন, যাতে ব্যর্থতা সম্পর্কে শুধু পড়ার বদলে সেটি ঘটতে দেখেন।

পুরো প্রক্রিয়ায় একটি কথা মনে রাখুন। checksum জানায়, আপনার কাছে থাকা byte-গুলো সেই byte কি না যেগুলো থেকে digest তৈরি হয়েছিল। কিন্তু digest কে তৈরি করেছে, তা checksum জানায় না। দ্বিতীয় প্রশ্নের জন্য signature এবং আপনার বিশ্বাস করা একটি key প্রয়োজন। এই guide-এর শেষ অংশে দুটির মধ্যে পার্থক্যটি ঠিক কোথায়, তা দেখানো হয়েছে।

অনুশীলনের জন্য একটি ফাইল তৈরি করুন

একটি অস্থায়ী ডিরেক্টরিতে কাজ করুন, যাতে এখানকার কোনো কিছু সিস্টেমের অন্য অংশে প্রভাব না ফেলে। নিচের প্রতিটি কমান্ড GNU coreutils-এর অংশ। এগুলো যেকোনো Ubuntu বা Debian সার্ভারে থাকা মৌলিক কমান্ড সেটের অন্তর্ভুক্ত, তাই কিছু ইনস্টল করার প্রয়োজন নেই।

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

আপনি একটি লাইন পাবেন: 64টি hexadecimal অক্ষর, এরপর দুটি space, তারপর ফাইলের নাম। ওই 64টি অক্ষর হলো ফাইলটির digest। কমান্ডটি আবার চালালে লাইনটি একই থাকবে, কারণ hashing deterministic: একই input থেকে সবসময় একই output তৈরি হয়। ফাইলের একটি অক্ষর পরিবর্তন করে আবার কমান্ডটি চালালে digest সামান্য পরিবর্তিত হবে না। এটি সম্পূর্ণ ভিন্ন দেখাবে, কারণ input-এর একটি bit পরিবর্তন করলে output-এর প্রায় অর্ধেক bit পরিবর্তিত হয়। এই বৈশিষ্ট্যের কারণেই 4 GB-এর একটি image-এর পরিবর্তে 64 অক্ষরের একটি string ব্যবহার করা যায়।

একটি SHA256SUMS ফাইল সংরক্ষণ করুন, তারপর সেটি যাচাই করুন

স্ক্রিনে দেখানো digest এক দিন পর আর কাজে লাগে না। সেটি একটি ফাইলে লিখুন, sha256sum নিজে যে format-এ লেখে সেই format-এ, যাতে tool পরে সেটি পড়তে পারে।

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

sha256sum -c তালিকার প্রতিটি line পড়ে, সেই line-এ উল্লিখিত file-এর hash তৈরি করে এবং দুইটি digest তুলনা করে। সফলভাবে চললে প্রতি file-এর জন্য একটি line দেখায়:

payload.txt: OK

Exit status-ও পরীক্ষা করুন, কারণ script সেটিই পড়ে; text পড়ে না। সফলভাবে চলার পরে echo $?, 0 দেখায়। SHA256SUMS নামটি কোনো বাধ্যতামূলক নিয়ম নয়, এটি একটি convention। তবে distribution এবং অধিকাংশ release page এই নাম ব্যবহার করে। তাই আপনিও এটি ব্যবহার করুন, যাতে পরের ব্যক্তি file না খুলেই বুঝতে পারেন এতে কী আছে।

এক বাইট পরিবর্তন করে check ব্যর্থ হতে দেখুন

এখন ইচ্ছাকৃতভাবে ফাইলটি নষ্ট করুন। এই কমান্ডটি offset 5-এ একটি মাত্র byte লিখবে এবং বাকি সব অপরিবর্তিত রাখবে। ফলে ফাইলের length ও name একই থাকবে।

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 করবে। তখন আপনি অনেক বেশি স্পষ্ট ধরনের ক্ষতি পরীক্ষা করতেন। এখন check কমান্ডটি দেখাবে:

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

echo $?, 1 প্রিন্ট করে। FAILED-এর অর্থ হলো ফাইলটি পড়া হয়েছে, কিন্তু এর digest তালিকায় থাকা digest-এর সঙ্গে মেলেনি। মূল byte-গুলো ফিরিয়ে দিন এবং নিশ্চিত করুন যে check আবার OK অবস্থায় ফিরেছে:

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

এটাই সম্পূর্ণ পদ্ধতি। ফাইলের যেকোনো স্থানে একটি byte-এর পার্থক্য থাকলেই FAILED তৈরি হয়। সংযোগ বিচ্ছিন্ন হওয়ার কারণে মাঝপথে থেমে যাওয়া download, গতকালের build সরবরাহ করা mirror, transit-এর সময় ফাইল পরিবর্তন করা proxy, অথবা ভুল block ফেরত দেওয়া disk—সব ক্ষেত্রেই একই ফল দেখা যাবে।

যখন তালিকায় এমন একটি ফাইলের নাম থাকে যা আপনি download করেননি

একটি distribution-এর প্রকৃত SHA256SUMS ফাইলে project-এর release করা প্রতিটি image-এর তালিকা থাকে, এবং আপনি সেগুলোর একটি download করেছেন। এখানে সেই পরিস্থিতিটি পুনরায় তৈরি করুন।

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 একটি ভিন্ন ধরনের failure, FAILED-এর মতো নয়, এবং দুটিকে গুলিয়ে ফেললে অপ্রয়োজনীয় সময় নষ্ট হয়। FAILED মানে file-এর bytes সঠিক নয়। FAILED open or read মানে sha256sum file-টি একেবারেই পায়নি, তাই কোনো তুলনা করা হয়নি। প্রকৃত download-এর ক্ষেত্রে সাধারণ কারণ হলো working directory, কারণ তালিকার নামগুলো command চালানোর directory-র সাপেক্ষে লেখা থাকে। file থাকা directory-তে পরিবর্তন করুন এবং command-টি আবার চালান। আপনি আসলে যে file-গুলোতে যাচাই করতে চান, শুধু সেগুলোর জন্য এটি ব্যবহার করুন:

sha256sum --ignore-missing -c SHA256SUMS.all

এটি payload.txt: OK মুদ্রণ করে এবং 0 exit status দিয়ে বন্ধ হয়। তালিকাভুক্ত কোনো নামই উপস্থিত না থাকলে --ignore-missing শূন্য file-এ নীরবে সফল হয় না। এটি no file was verified জানায় এবং non-zero exit status দিয়ে বন্ধ হয়। এটাই প্রত্যাশিত আচরণ, কারণ কোনো কিছু যাচাই না করেও pass হওয়া এমন failure, যা আপনি কখনো বুঝতে পারতেন না।

চোখে না মিলিয়ে প্রকাশিত 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-এর মধ্যে দুটি space থাকে। এই কারণে format string-এও দুটি space রয়েছে। sha256sum যে format লেখে, এটিই তার গঠন। -c-ও এই গঠন পার্স করে। শুধু একটি digest থাকা file কোনো checksum line নয়। তাই কোন file বোঝানো হয়েছে তা অনুমান না করে check পুরো file-টিকেই no properly formatted checksum lines found দিয়ে প্রত্যাখ্যান করে। কিছু project-এর প্রকাশিত format BSD tagged style অনুসরণ করে। সেখানে SHA256 (payload.txt) = -এর পরে digest থাকে। GNU coreutils sha256sum --tag payload.txt দিয়ে এই format লেখে এবং -c দিয়ে আবার পড়ে। তাই সংরক্ষণের জন্য যেকোনো একটি format ব্যবহার করা যায়।

check অস্বাভাবিক আচরণ করলে cat -A SHA256SUMS দিয়ে list-টি পরীক্ষা করুন। এটি প্রতিটি line-এর শেষে $ চিহ্ন দেখায় এবং সাধারণভাবে অদৃশ্য থাকা character-গুলো দৃশ্যমান করে। ^M$ দিয়ে শেষ হওয়া line Windows editor থেকে carriage return নিয়ে এসেছে। GNU sha256sum এই trailing character উপেক্ষা করে এবং তবু OK প্রিন্ট করে। তাই CRLF list আপনার check নষ্ট করছে না। তবে coreutils-এর বাইরের tool-গুলো এ বিষয়ে কম সহনশীল। সংরক্ষণ করা copy-টি tr -d '\r' < SHA256SUMS > SHA256SUMS.clean দিয়ে স্বাভাবিক করুন।

Checksum কী প্রমাণ করে, আর কী প্রমাণ করে না?

একটি checksum একটি বিষয় প্রমাণ করে: আপনার disk-এর byte-গুলোই প্রকাশিত digest তৈরি করেছে। এটি সম্পূর্ণভাবে আকস্মিক ক্ষয়ক্ষতি শনাক্ত করতে পারে। এমন অসতর্ক attacker-এর ক্ষেত্রেও এটি কার্যকর, যে download mirror-এ file বদলেছে কিন্তু digest প্রকাশকারী page-এ পরিবর্তন করতে পারেনি।

এটি file-এর লেখক কে, তা প্রমাণ করে না। একটি digest byte-সম্পর্কিত তথ্য, মানুষের পরিচয়সম্পর্কিত তথ্য নয়। একই page যদি file এবং digest দুটিই সরবরাহ করে, তাহলে যে ব্যক্তি একটিতে পরিবর্তন করতে পারে, সে অন্যটিতেও পরিবর্তন করতে পারে। সে ক্ষেত্রে আপনার OK line শুধু প্রমাণ করে যে mirror নিজের সঙ্গে একমত। তাই checksum চালানোর মূল নিয়ম হলো: file যেখান থেকে নিয়েছেন, digest সেখান থেকে নেবেন না। উদাহরণস্বরূপ, image যদি mirror বা torrent থেকে নেওয়া হয়, তাহলে TLS (transport layer security)-এর মাধ্যমে project's own domain থেকে digest নিন। এতে attacker-কে একটি জায়গার বদলে দুটি জায়গা নিয়ন্ত্রণ করতে হবে। তবে যাচাই করা byte-গুলো চালানোর পরে কী করবে, সে সম্পর্কে checksum কিছু বলে না। আপনার হয়ে কাজ করে এমন যেকোনো executable জিনিসের ক্ষেত্রেই এটি আলাদা করে বিবেচনা করা দরকার—install script থেকে শুরু করে আপনার agent-এর permission নিয়ে চলা dsh plugin পর্যন্ত।

Algorithm-ও গুরুত্বপূর্ণ। SHA-256 (secure hash algorithm, 256-bit output)-এর ক্ষেত্রে August 2026 পর্যন্ত কোনো পরিচিত collision নেই। এ কারণেই publisher-রা এটি ব্যবহার করে। MD5 (message digest 5) এবং SHA-1 নির্ভরযোগ্য নয়: একই MD5 digest-সহ দুটি ভিন্ন file 2004 সাল থেকেই তৈরি করা সম্ভব, এবং chosen-prefix SHA-1 collision 2020 সালে প্রকাশিত হয়েছে। একটি MD5SUMS file truncated download শনাক্ত করতে পারে, কারণ এলোমেলো corruption crafted collision নয়। তবে আপনাকে প্রতারণা করার উদ্দেশ্যে কাজ করা কাউকে এটি থামাতে পারে না। কোনো project যদি দুটিই প্রকাশ করে, তাহলে SHA-256 line ব্যবহার করুন।

স্বাক্ষর যেখানে নিয়ন্ত্রণ নেয়

একটি signature digest যে ফাঁক খোলা রাখে, তা বন্ধ করে। Publisher private key দিয়ে digest file-এ স্বাক্ষর করে, আর আপনি তাদের public key দিয়ে তা যাচাই করেন: gpg --verify SHA256SUMS.asc SHA256SUMS। এটি সফল হলে digest-এর তালিকাটি ওই key-এর অধিকারীর কাছ থেকে এসেছে। এরপর sha256sum -c SHA256SUMS আপনার disk-এর file-টিকে তালিকার সঙ্গে মিলিয়ে দেয়, এবং এই chain key থেকে শুরু করে শেষ পর্যন্ত bytes পর্যন্ত পৌঁছে যায়।

দুর্বল দিকটি তখন key-তে গিয়ে কেন্দ্রীভূত হয়। যে page file সরবরাহ করেছে, সেখান থেকেই key নিলে attacker উভয় অংশের নিয়ন্ত্রণ পেয়ে যায়। GnuPG এ বিষয়ে স্পষ্ট, এবং প্রথম verification-এ Good signature-এর সঙ্গে WARNING: This key is not certified with a trusted signature! প্রদর্শিত হয়। Good signature-এর অর্থ হলো গাণিতিক যাচাই সফল হয়েছে। এর অর্থ এই নয় যে key-টি আপনার ধারণার project-এরই। দ্বিতীয় কোনো source থেকে fingerprint সংগ্রহ করুন, যেমন ভিন্ন domain-এ থাকা project-এর documentation অথবা এমন কোনো distribution package যা আগে থেকেই key সরবরাহ করে। এরপর শেষ আটটি character নয়, সম্পূর্ণ fingerprint তুলনা করুন। একই কারণে SSH private key-এর মতো একই সতর্কতা এখানেও প্রযোজ্য: key-ই trust-এর সিদ্ধান্ত নির্ধারণ করে, এবং পরবর্তী সবকিছু সেই সিদ্ধান্তের ওপর নির্ভর করে।

Reproducible build এই ধারণাকে আরও এক ধাপ এগিয়ে নেয়। প্রকাশিত digest এখনও আপনাকে একটি machine-এ তৈরি binary-এর ওপর নির্ভরশীল করে রাখে। কোনো project-এর build reproducible হলে যে কেউ একই source compile করে byte-identical output পেতে পারে। ফলে independent builder-রা একটি server-এর বক্তব্য মেনে নিতে বলার পরিবর্তে প্রকাশিত digest নিশ্চিত করতে পারে। Automated pipeline এবং machine-written patch-এর মাধ্যমে প্রতি বছর আরও বেশি code আসায় এর গুরুত্বও বাড়ছে। কোনো build-এ কী গ্রহণ করবেন, তা একটি policy-সংক্রান্ত প্রশ্ন। আর AI-assisted code-এর জন্য open source policy supply chain-এর অন্য প্রান্ত থেকেও একই বিষয় নিয়ে কাজ করে।

আপনার package manager ইতিমধ্যে এটি করে

Debian এবং Ubuntu-তে, কোনো অতিরিক্ত নির্দেশ ছাড়াই প্রতিবার install-এর সময় apt এই ধাপগুলো চালায়। Package index-এ প্রতিটি .deb file-এর জন্য একটি SHA-256 digest থাকে। Release file-এ ওই index file-গুলোর digest থাকে, এবং InRelease-এ Release-এর ওপর একটি signature থাকে। এই signature /usr/share/keyrings এবং /etc/apt/trusted.gpg.d-এ থাকা key-এর সঙ্গে মিলিয়ে যাচাই করা হয়। এই chain ভেঙে গেলে apt তা জানায়: কোনো third-party 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 করতে বলে, তখন এর সঙ্গে তুলনা করার মানদণ্ড এটাই। এতে byte যাচাই করার কোনো ব্যবস্থা থাকে না, এবং আপনি byte-গুলো দেখতেও পান না। Server একটি script-কে এক ধরনের content এবং browser-কে অন্য ধরনের content দিতে পারে। পরে পরীক্ষা করার জন্য আপনার কাছে কোনো copy-ও থাকে না। curl -fsSL <url> -o install.sh দিয়ে file-এ download করুন, তার hash তৈরি করুন, less দিয়ে পড়ে দেখুন, এবং এরপরই চালান। এই অভ্যাসে প্রায় বিশ সেকেন্ড লাগে। Box-এ অন্য কিছু install করার আগে একটি নতুন VPS-এর প্রথম দশ মিনিটেই এই অভ্যাস শুরু করা উচিত।

হাতে ইনস্টল করা জিনিসগুলোর জন্য digest-এর তালিকা রাখুন

apt দিয়ে ইনস্টল করা package-গুলোর হিসাব রাখা হয়। আপনি /usr/local/bin-এ কপি করা binary-এর হিসাব রাখা হয় না, এবং সিস্টেমে কোনো প্রক্রিয়া সেটি monitor করে না। একটি digest-এর তালিকা হলে প্রয়োজনে তা যাচাই করা যায়:

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

সব file মিলে গেলে --quiet কোনো output দেয় না। কোনো file না মিললে শুধু ব্যর্থ হওয়া line-গুলো দেখায়। তাই নীরব output-ই pass, এবং echo $? এটি 0 দিয়ে নিশ্চিত করে। Scheduled job-এ ব্যবহার করার জন্য এটাই উপযুক্ত পদ্ধতি। --status আরও এগিয়ে কোনো output-ই দেয় না; আপনি শুধু exit status পান। sha256sum /usr/local/bin/* > ~/local-bin.sha256 দিয়ে একই pattern প্রকৃত file-এর ওপর প্রয়োগ করলে একটি baseline তৈরি হয়। Path-গুলো তালিকায় আপনি যেভাবে লিখেছেন, ঠিক সেভাবেই সংরক্ষিত হয়। তাই absolute path ব্যবহার করলে যেকোনো directory থেকে check কাজ করবে।

এই baseline-এর সীমাবদ্ধতা স্পষ্টভাবে বুঝুন। এটি পরিবর্তিত file শনাক্ত করে। কিন্তু যে attacker ইতিমধ্যে root access পেয়েছে, তাকে শনাক্ত করতে পারে না। কারণ সেই attacker binary পুনর্লিখতে পারার মতো সহজেই inventory.sha256 পুনর্লিখতে পারে। তালিকাটি মেশিনের বাইরে রাখুন, যদি এর কোনো বাস্তব মূল্য রাখতে চান। এটি আরও বিস্তৃত প্রশ্নের অংশ—আপনি আসলে VPS-এর কতটা বিশ্বাস করছেন এবং এর নিচের disk-এ আর কে access করতে পারে।

FAQ

মিল থাকা checksum কি download-টি নিরাপদ প্রমাণ করে?

না। এর অর্থ হলো, আপনার কাছে থাকা bytes যে digest-এর সঙ্গে তুলনা করেছেন, তার সঙ্গে মিলে গেছে। digest প্রকাশ করা page-টি যদি attacker-এর নিয়ন্ত্রণে থাকে, তবে attacker নিজের file-এর digest প্রকাশ করতে পারে এবং আপনার check OK দেখাবে। মিল consistency-এর প্রমাণ মাত্র। নিরাপত্তার দাবি করতে হলে ভিন্ন উৎস থেকে সংগ্রহ করা key দিয়ে signature verify করতে হবে। তখনই digest সেই key-এর trust পায়।

sha256sum -c কেন FAILED open or read দেখায়?

কারণ এটি file পড়েনি। তার ঠিক আগের একটি পৃথক line-এ No such file or directory এবং যে নামটি এটি খুঁজেছিল তা বলা আছে। SHA256SUMS file-এর নামগুলো আপনি যে directory-তে command চালান, তার তুলনায় relative। তাই download থাকা directory-তে গিয়ে command-টি আবার চালান। তালিকায় download না করা file-এর নামও থাকলে --ignore-missing যোগ করুন। কোনো open or read ছাড়া সাধারণ FAILED দেখা গেলে পরিস্থিতি বিপরীত: file পড়া হয়েছে, কিন্তু তার digest মেলেনি।

Download যাচাইয়ের জন্য MD5 কি যথেষ্ট?

অনিচ্ছাকৃত ক্ষতির ক্ষেত্রে হ্যাঁ। অসম্পূর্ণ transfer বা disk-এর ত্রুটিপূর্ণ block থেকে কাকতালীয়ভাবে matching MD5 digest তৈরি হবে না। attacker-এর বিরুদ্ধে নয়। একই MD5 digest-যুক্ত দুটি ভিন্ন file 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 দুটিই দিলে উভয় check চালান। signature digest list-কে trustworthy করে, আর digest list download করা file-কে trustworthy করে।

Web page-এ প্রকাশিত digest-এর সঙ্গে একটি file কীভাবে যাচাই করব?

চোখে দেখে character তুলনা করবেন না। একই line-এ digest এবং file name লিখুন, দুটির মধ্যে দুইটি space রাখুন। এরপর ওই file-এর বিরুদ্ধে sha256sum -c চালান এবং এটি যে OK বা FAILED দেখায় তা পড়ুন। printf '%s %s\n' দিয়ে line তৈরি করলে formatting-এর ভুল এড়ানো যায়। এই ভুলের কারণে sha256sum file-টি no properly formatted checksum lines found দিয়ে reject করতে পারে।