Linux میں downloads کو checksum سے کیسے verify کریں

دو منٹ میں checksum کے ذریعے download کی تصدیق کریں

checksum کے ذریعے download کی تصدیق کرنے کے لیے موصول ہونے والی file کا hash بنائیں اور کسی tool کو یہ hash publisher کے فراہم کردہ hash سے ملانے دیں۔ sha256sum یہ دونوں کام کرتا ہے: اکیلے استعمال ہونے پر یہ digest دکھاتا ہے، جبکہ -c کے ساتھ یہ digests کی فہرست پڑھ کر بتاتا ہے کہ کون سی files match کرتی ہیں۔ اس guide میں آپ کی بنائی ہوئی file پر مکمل عمل دکھایا جائے گا، پھر جان بوجھ کر اس file میں تبدیلی کی جائے گی تاکہ آپ failure کو پڑھنے کے بجائے خود واقع ہوتے دیکھیں۔

پورے عمل کے دوران یہ ایک جملہ ذہن میں رکھیں۔ checksum بتاتا ہے کہ آپ کے پاس موجود bytes وہی bytes ہیں جن سے digest تیار ہوا تھا، لیکن یہ نہیں بتاتا کہ وہ bytes یا digest کس نے تیار کیا۔ دوسرے سوال کے لیے signature اور آپ کے قابلِ اعتماد key کی ضرورت ہوتی ہے۔ اس guide کا آخری حصہ واضح طور پر دکھاتا ہے کہ دونوں کے درمیان حد کہاں قائم ہوتی ہے۔

مشق کے لیے ایک فائل بنائیں

ایک عارضی ڈائریکٹری میں کام کریں تاکہ یہاں چلایا گیا کوئی بھی کام سسٹم کے باقی حصے کو متاثر نہ کرے۔ ذیل کے تمام commands GNU coreutils سے آتے ہیں۔ یہ بنیادی command set ہر Ubuntu یا Debian سرور پر موجود ہوتا ہے، اس لیے کچھ 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، پھر فائل کا نام۔ یہ 64 characters فائل کا digest ہیں۔ command دوبارہ چلائیں تو سطر بالکل یکساں ہوگی، کیونکہ hashing deterministic ہوتی ہے: ایک ہی input ہمیشہ ایک ہی output دیتا ہے۔ فائل کا ایک character تبدیل کرکے command دوبارہ چلائیں تو digest معمولی سا تبدیل نہیں ہوگا۔ یہ مکمل طور پر مختلف دکھائی دے گا، کیونکہ ایک input bit flip ہونے سے output کی تقریباً نصف bits flip ہو جاتی ہیں۔ یہی خاصیت 64-character string کو 4 GB image کے قابلِ استعمال متبادل کے طور پر کارآمد بناتی ہے۔

SHA256SUMS فائل محفوظ کریں، پھر اس کی جانچ کریں

اسکرین پر دکھائی دینے والا digest اگلے دن بے کار ہوتا ہے۔ اسے ایک فائل میں اسی format میں لکھیں جس format میں sha256sum خود اسے لکھتا ہے، تاکہ یہ tool بعد میں اسے دوبارہ پڑھ سکے۔

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

sha256sum -c فہرست کی ہر سطر پڑھتا ہے، اس سطر میں نامزد فائل کا hash بناتا ہے، اور دونوں digests کا موازنہ کرتا ہے۔ درست execution ہر فائل کے لیے ایک سطر دکھاتا ہے:

payload.txt: OK

exit status بھی چیک کریں، کیونکہ script اسی کو پڑھتی ہے، متن کو نہیں۔ کامیاب execution کے بعد echo $?، 0 دکھاتا ہے۔ SHA256SUMS نام ایک convention ہے، لازمی اصول نہیں، لیکن distributions اور زیادہ تر release pages یہی نام استعمال کرتے ہیں۔ اس لیے آپ بھی یہی نام استعمال کریں، تاکہ اگلے شخص کو فائل کھولے بغیر معلوم ہو جائے کہ اس میں کیا موجود ہے۔

ایک byte تبدیل کریں اور check کو fail ہوتے دیکھیں

اب جان بوجھ کر file میں خرابی پیدا کریں۔ یہ offset 5 پر صرف ایک byte لکھتا ہے اور باقی سب کچھ جوں کا توں رہتا ہے، اس لیے file کی 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 لکھنا بند کرنے کے مقام پر file کو truncate کر دیتا ہے، اور آپ کہیں زیادہ واضح نوعیت کی خرابی کو test کر رہے ہوتے۔ اب check یہ output دیتا ہے:

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

echo $?، 1 print کرتا ہے۔ FAILED کا مطلب ہے کہ file پڑھی گئی، لیکن اس کا digest list میں موجود digest سے match نہیں ہوا۔ اصل bytes واپس رکھیں اور تصدیق کریں کہ check دوبارہ OK پر آ جاتا ہے:

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

یہی مکمل طریقہ ہے۔ file میں کہیں بھی ایک byte کا فرق FAILED پیدا کرتا ہے۔ connection منقطع ہونے سے ادھورا رہ جانے والا download، کل کی build فراہم کرنے والا mirror، transit کے دوران file کو rewrite کرنے والا proxy، یا bad block واپس کرنے والی disk: یہ سب اسی ایک line پر ظاہر ہوتے ہیں۔

جب فہرست میں ایسی file کا نام ہو جسے آپ نے download نہیں کیا

حقیقی SHA256SUMS file میں distribution کی جانب سے release کی گئی ہر image شامل ہوتی ہے، جبکہ آپ نے ان میں سے صرف ایک 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، FAILED سے مختلف failure ہے، اور دونوں کو ایک سمجھنے سے وقت ضائع ہوتا ہے۔ FAILED کا مطلب ہے کہ bytes غلط ہیں۔ FAILED open or read کا مطلب ہے کہ sha256sum کو file ملی ہی نہیں، اس لیے کوئی موازنہ نہیں کیا گیا۔ حقیقی download میں عام وجہ working directory ہوتی ہے، کیونکہ فہرست میں موجود نام اس directory کے نسبت ہوتے ہیں جہاں سے آپ command چلاتے ہیں۔ اس directory میں جائیں جس میں file موجود ہے، پھر command دوبارہ چلائیں۔ صرف ان files کو check کرنے کے لیے جو آپ کے پاس واقعی موجود ہیں، یہ command چلائیں:

sha256sum --ignore-missing -c SHA256SUMS.all

یہ payload.txt: OK print کرتا ہے اور 0 پر exit ہوتا ہے۔ اگر فہرست میں موجود کوئی بھی نام دستیاب نہ ہو تو --ignore-missing صفر files پر خاموشی سے کامیاب نہیں ہوتا۔ یہ no file was verified report کرتا ہے اور non-zero پر exit ہوتا ہے۔ یہی مطلوبہ رویہ ہے، کیونکہ ایسی pass جو کسی چیز کو check ہی نہ کرے، وہ failure ہے جس کا آپ کو کبھی پتا نہیں چلتا۔

آنکھ سے دیکھے بغیر شائع کردہ digest چیک کریں

64 hexadecimal characters کا آنکھ سے موازنہ کرنے پر یہ عادت واقعی ناکام ہو جاتی ہے۔ لوگ پہلے چار characters اور آخری چار characters دیکھ کر اسے match قرار دے دیتے ہیں، اور ایک پرعزم حملہ آور بھی عین اسی موازنے کی توقع کرتا ہے۔ اس کے بجائے tool کو موازنہ کرنے دیں۔ EXPECTED میں publisher سے copy کیا ہوا digest رکھیں۔ اس کے لیے EXPECTED= کے بعد pasted value درج کریں، پھر وہ single line بنائیں جس کی -c کو توقع ہے:

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

digest اور file name کے درمیان دو spaces ہوتی ہیں، اسی لیے format string میں بھی دو spaces شامل ہیں۔ یہی وہ format ہے جسے sha256sum لکھتا ہے اور -c parse کرتا ہے۔ ایسی file جس میں صرف digest ہو، checksum line نہیں ہوتی۔ اس لیے check پوری file کو no properly formatted checksum lines found کے ساتھ reject کر دیتا ہے، بجائے اس کے کہ اندازہ لگائے کہ آپ کی مراد کون سی file تھی۔ بعض projects اس کے بجائے BSD tagged style شائع کرتے ہیں، یعنی SHA256 (payload.txt) = کے بعد digest۔ GNU coreutils اس format کو sha256sum --tag payload.txt کے ساتھ لکھتا ہے اور -c کے ساتھ دوبارہ پڑھتا ہے، اس لیے محفوظ کرنے کے لیے دونوں formats درست ہیں۔

جب check غیر متوقع رویہ دکھائے تو cat -A SHA256SUMS کے ساتھ list خود دیکھیں۔ یہ ہر line کے اختتام پر $ دکھاتا ہے اور ایسے characters بھی ظاہر کرتا ہے جو عام طور پر نظر نہیں آتے۔ ^M$ پر ختم ہونے والی line میں Windows editor سے carriage return شامل ہو گیا ہے۔ GNU sha256sum اس آخری character کو نظرانداز کرتا ہے اور پھر بھی OK print کرتا ہے۔ اس لیے CRLF list آپ کے check کو خراب نہیں کر رہی، تاہم coreutils کے باہر کے tools اسے اتنی آسانی سے قبول نہیں کرتے۔ اپنی محفوظ copy کو tr -d '\r' < SHA256SUMS > SHA256SUMS.clean کے ساتھ normalise کریں۔

چیک سم کیا ثابت کرتا ہے، اور کیا ثابت نہیں کرتا؟

چیک سم صرف ایک بات ثابت کرتا ہے: آپ کی disk پر موجود bytes وہی bytes ہیں جن سے شائع کردہ digest تیار ہوا تھا۔ یہ اتفاقی نقصان کے معاملے کو مکمل طور پر شامل کرتا ہے۔ یہ ایسے غیر محتاط حملہ آور کے معاملے میں بھی مدد دیتا ہے جس نے download mirror پر file تبدیل کر دی ہو، لیکن اس صفحے کو تبدیل نہ کر سکا ہو جہاں digest شائع کیا گیا تھا۔

یہ file کے مصنف یا ماخذ کے بارے میں کچھ ثابت نہیں کرتا۔ Digest bytes کے بارے میں ایک حقیقت ہے، لوگوں کے بارے میں نہیں۔ اگر ایک ہی صفحہ file اور digest دونوں فراہم کرتا ہے، تو جو شخص ایک کو تبدیل کر سکتا ہے وہ دوسرے کو بھی تبدیل کر سکتا ہے، اور آپ کی OK line صرف یہ بتاتی ہے کہ mirror اپنے ہی مواد سے متفق ہے۔ اس لیے وہ اصول یاد رکھیں جو checksums کو چلانے کے قابل بناتا ہے: digest اس جگہ کے علاوہ کہیں اور سے حاصل کریں جہاں سے file حاصل کی تھی۔ مثلاً image کسی mirror یا torrent سے حاصل کریں، لیکن digest کو project کے اپنے domain سے TLS (transport layer security) کے ذریعے حاصل کریں۔ اب حملہ آور کو ایک کے بجائے دو جگہوں کا اختیار حاصل کرنا ہوگا۔

الگورتھم بھی اہم ہے۔ 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 کا پتا چلا لیتی ہے، کیونکہ اتفاقی corruption، crafted collision نہیں ہوتی۔ لیکن یہ ایسے شخص کو نہیں روک سکتی جو آپ کو دھوکا دینے کی کوشش کر رہا ہو۔ جب کوئی project دونوں فراہم کرے تو SHA-256 line استعمال کریں۔

جب دستخط مرکزی کردار ادا کرتے ہیں

دستخط اس خلا کو پُر کرتے ہیں جو digest کھلا چھوڑ دیتا ہے۔ publisher نجی key سے digest file پر دستخط کرتا ہے، اور آپ اسے اس کی public key سے جانچتے ہیں: gpg --verify SHA256SUMS.asc SHA256SUMS۔ اگر یہ جانچ کامیاب ہو جائے تو digests کی فہرست اسی شخص یا ادارے سے آئی ہے جس کے پاس وہ key ہے۔ پھر sha256sum -c SHA256SUMS آپ کی disk پر موجود file کو فہرست سے منسلک کرتا ہے، اور یہ chain key سے شروع ہو کر bytes تک پہنچتی ہے۔

کمزوری اب key پر منتقل ہو جاتی ہے۔ جس page نے file فراہم کی ہو، اسی page سے key حاصل کرنے پر حملہ آور کو دونوں حصے واپس مل جاتے ہیں۔ GnuPG اس بارے میں واضح ہے، اور پہلی verification میں Good signature کے ساتھ WARNING: This key is not certified with a trusted signature! بھی دکھائی دیتا ہے۔ Good signature کا مطلب ہے کہ ریاضیاتی جانچ درست ہے۔ اس کا مطلب یہ نہیں کہ key اسی project سے تعلق رکھتی ہے جس کا آپ تصور کر رہے ہیں۔ fingerprint کسی دوسرے ذریعے سے حاصل کریں، مثلاً مختلف domain پر موجود project کی documentation سے، یا کسی ایسے distribution package سے جس میں key پہلے سے شامل ہو، اور آخری 8 characters کے بجائے مکمل fingerprint کا موازنہ کریں۔ یہی احتیاط SSH private key کے لیے بھی ضروری ہے، کیونکہ وجہ وہی ہے: key ہی اعتماد کا فیصلہ کرتی ہے، اور اس کے بعد آنے والی ہر چیز اسی اعتماد پر منحصر ہوتی ہے۔

Reproducible builds اس تصور کو ایک قدم آگے لے جاتی ہیں۔ شائع کردہ digest اب بھی آپ کو اس binary سے جوڑتا ہے جسے ایک machine نے build کیا ہو۔ جب کسی project کی build reproducible ہو تو کوئی بھی شخص اسی source کو compile کر کے بالکل یکساں output حاصل کر سکتا ہے۔ اس طرح independent builders شائع کردہ digest کی تصدیق کر سکتے ہیں، بجائے اس کے کہ آپ کو ایک server کی بات پر اعتماد کرنا پڑے۔ یہ اہمیت ہر سال بڑھ رہی ہے، کیونکہ زیادہ code automated pipelines اور machine-written patches کے ذریعے آ رہا ہے۔ Build میں کیا شامل کرنا ہے، یہ policy کا سوال ہے، اور AI-assisted code کے لیے open source policies supply chain کے اسی عمل کو دوسرے سرے سے دیکھتی ہیں۔

آپ کا package manager یہ کام پہلے ہی آپ کے لیے کرتا ہے

Debian اور Ubuntu پر، apt ہر installation کے وقت بغیر پوچھے یہ chain چلاتا ہے۔ package index میں ہر .deb file کا SHA-256 digest موجود ہوتا ہے۔ Release file میں ان index files کے digests ہوتے ہیں، جبکہ InRelease میں Release پر دستخط موجود ہوتا ہے۔ اس دستخط کی تصدیق /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، یا جب حاصل کیا گیا index signed Release سے مطابقت نہ رکھتا ہو تو Hash Sum mismatch۔ عموماً اس کا مطلب ہوتا ہے کہ caching proxy نے پرانی file فراہم کی ہے یا آپ نے mirror کو synchronization کے دوران حاصل کیا ہے۔

جب کسی project کا home page آپ کو curl سے script کو براہ راست shell میں pipe کرنے کا کہتا ہے تو اسی معیار کو بنیاد بنائیں۔ bytes کی کوئی verification نہیں ہوتی اور آپ انہیں دیکھ بھی نہیں پاتے۔ server کسی script کو ایک content دے سکتا ہے اور browser کو دوسرا، جبکہ بعد میں جانچنے کے لیے آپ کے پاس کوئی copy بھی نہیں ہوتی۔ curl -fsSL <url> -o install.sh کے ذریعے file download کریں، اس کا hash بنائیں، less کے ذریعے اسے پڑھ کر جانچیں، اور اس کے بعد ہی چلائیں۔ اس عادت میں تقریباً بیس seconds لگتے ہیں۔ یہی عادت نئے VPS کے ابتدائی دس منٹ میں اپنانا مفید ہے، یعنی box پر کوئی اور چیز install کرنے سے پہلے۔

جو کچھ ہاتھ سے انسٹال کریں، اس کے digests کی فہرست رکھیں

apt سے انسٹال کیے گئے packages کا ریکارڈ رکھا جاتا ہے۔ /usr/local/bin میں کاپی کی گئی binary کا ریکارڈ نہیں رکھا جاتا، اور سسٹم پر کوئی عمل اس کی نگرانی نہیں کرتا۔ digest list اس صورتِ حال کو ایسی چیز میں بدل دیتی ہے جسے آپ ضرورت کے وقت چیک کر سکتے ہیں:

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

جب ہر file مطابقت رکھتی ہو تو --quiet کچھ print نہیں کرتا۔ اگر کچھ files مطابقت نہ رکھتی ہوں تو یہ صرف ناکام ہونے والی lines print کرتا ہے۔ اس لیے خاموش output کامیابی کی علامت ہے، اور echo $? اسے 0 کے ساتھ confirm کرتا ہے۔ Scheduled job میں یہی شکل استعمال کریں۔ --status اس سے ایک قدم آگے جاتا ہے اور کوئی output بالکل print نہیں کرتا؛ آپ کے پاس صرف exit status رہ جاتا ہے۔ اسی pattern کو اصل files پر sha256sum /usr/local/bin/* > ~/local-bin.sha256 کے ساتھ لاگو کریں، تو baseline تیار ہو جاتی ہے۔ Paths کو list میں بالکل اسی طرح محفوظ کیا جاتا ہے جیسے آپ نے انہیں type کیا ہو، اس لیے absolute paths استعمال کرنے سے یہ check کسی بھی directory سے کام کرتا ہے۔

واضح رہیں کہ اس baseline کی حدود کیا ہیں۔ یہ تبدیل شدہ file کا پتا چلا سکتی ہے۔ یہ ایسے attacker کا پتا نہیں چلا سکتی جس کے پاس پہلے ہی root access ہو، کیونکہ وہ attacker inventory.sha256 کو اتنی آسانی سے دوبارہ لکھ سکتا ہے جتنی آسانی سے اس نے binary کو دوبارہ لکھا تھا۔ اگر آپ چاہتے ہیں کہ اس list کی کوئی حقیقی افادیت ہو تو اسے machine سے باہر رکھیں۔ یہ اس بڑے سوال کا بھی حصہ ہے کہ آپ واقعی VPS پر کس حد تک اعتماد کر رہے ہیں اور اس کے نیچے موجود disk تک اور کون پہنچ سکتا ہے۔

FAQ

کیا matching checksum کا مطلب ہے کہ download محفوظ ہے؟

نہیں۔ اس کا مطلب صرف یہ ہے کہ آپ کے پاس موجود bytes اس digest سے match کرتے ہیں جس کے ساتھ آپ نے ان کا موازنہ کیا۔ اگر attacker اس page کو control کرتا ہے جہاں digest شائع کیا گیا تھا، تو وہ اپنی file کا digest شائع کر دے گا اور آپ کی check OK دکھائے گی۔ Match صرف consistency کا دعویٰ ہے۔ Safety کے دعوے کے لیے ایسی signature درکار ہوتی ہے جس کی verification آپ نے کسی مختلف source سے حاصل کردہ key کے خلاف کی ہو۔ اس کے بعد ہی digest کو اس اعتماد کا فائدہ ملتا ہے۔

sha256sum -c FAILED open or read کیوں دکھاتا ہے؟

کیونکہ اس نے file پڑھی ہی نہیں۔ اس کے بالکل اوپر ایک الگ line میں No such file or directory لکھا ہوتا ہے، جس میں وہ مطلوبہ نام دیا گیا ہے جسے اس نے تلاش کیا۔ SHA256SUMS file کے اندر موجود names اس directory کے نسبت سے ہوتے ہیں جس میں آپ command چلاتے ہیں۔ اس لیے download رکھنے والی directory میں جائیں اور command دوبارہ چلائیں۔ اگر list میں ایسی files کے names بھی ہوں جو آپ نے download نہیں کیں، تو --ignore-missing شامل کریں۔ اس کے برعکس، بغیر open or read کے سادہ FAILED کا مطلب ہے کہ file پڑھی گئی، لیکن اس کا digest match نہیں ہوا۔

کیا download کی verification کے لیے MD5 کافی ہے؟

حادثاتی نقصان کی صورت میں ہاں۔ نامکمل transfer یا disk کا خراب block اتفاقاً matching MD5 digest پیدا نہیں کرے گا۔ لیکن attacker کے خلاف نہیں۔ 2004 سے دو مختلف files کو ایک ہی MD5 digest کے ساتھ بنانا ممکن ہے، اور 2020 میں SHA-1 chosen-prefix collision کا شکار ہو گیا۔ جب project دونوں فراہم کرے تو SHA-256 والی line استعمال کریں۔ صرف MD5 فراہم کرنے والے project کو پرانے release process کی علامت سمجھیں۔

sha256sum -c اور gpg --verify میں کیا فرق ہے؟

sha256sum -c ثابت کرتا ہے کہ file کسی digest سے match کرتی ہے۔ gpg --verify ثابت کرتا ہے کہ digest file پر کسی مخصوص private key کے holder نے signature کی ہے۔ یہ دونوں مختلف سوالات کے جواب دیتے ہیں، اس لیے جب project دونوں فراہم کرے تو دونوں commands چلائیں۔ Signature digest list کو قابلِ اعتماد بناتی ہے، اور digest list download کی گئی file کو قابلِ اعتماد بناتی ہے۔

web page پر چھپے ہوئے digest کے ساتھ ایک file کی verification کیسے کروں؟

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 کے ساتھ reject کر دیتا ہے۔