Linux میں checksum سے download کی تصدیق کیسے کریں

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

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

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

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

ایک scratch directory میں کام کریں تاکہ یہاں کی کوئی چیز سسٹم کے باقی حصے کو متاثر نہ کرے۔ ذیل میں موجود ہر command GNU coreutils سے ہے، جو ہر Ubuntu یا Debian server پر موجود بنیادی command set ہے، اس لیے کچھ install کرنے کی ضرورت نہیں۔

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

آپ کو ایک line ملے گی: 64 hexadecimal characters، اس کے بعد دو spaces، پھر file name۔ یہ 64 characters فائل کا digest ہیں۔ command دوبارہ چلائیں تو line بالکل یکساں ہوگی، کیونکہ hashing deterministic ہوتی ہے: ایک ہی input ہمیشہ ایک ہی output دیتا ہے۔ فائل کا ایک character تبدیل کر کے command دوبارہ چلائیں تو digest معمولی سا تبدیل نہیں ہوگا۔ یہ مکمل طور پر مختلف دکھائی دے گا، کیونکہ ایک input bit بدلنے سے output کی تقریباً نصف bits بدل جاتی ہیں۔ یہی خاصیت 64-character string کو 4 GB image کے قابلِ استعمال متبادل کے طور پر کام کرنے کے قابل بناتی ہے۔

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

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

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

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

payload.txt: OK

Exit status بھی چیک کریں، کیونکہ script اسی کو پڑھتی ہے اور متن کو نہیں پڑھتی۔ صاف طور پر مکمل ہونے کے بعد echo $?، 0 دکھاتا ہے۔ SHA256SUMS نام ایک convention ہے، لازمی اصول نہیں۔ تاہم 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 سے مطابقت نہیں رکھتا۔ اصل bytes واپس رکھیں اور تصدیق کریں کہ چیک دوبارہ OK پر آ جاتا ہے:

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

یہی مکمل طریقہ ہے۔ فائل میں کہیں بھی صرف ایک بائٹ کا فرق FAILED پیدا کرتا ہے۔ کنکشن منقطع ہونے سے ادھوری رہ جانے والی download، کل کا build فراہم کرنے والا mirror، transit کے دوران فائل کو تبدیل کرنے والا proxy، یا خراب block واپس کرنے والی disk: یہ سب اسی ایک سطر پر ظاہر ہوتے ہیں۔

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

حقیقی SHA256SUMS فائل میں distribution کی جانب سے project کی جاری کردہ ہر 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 کو فائل ملی ہی نہیں، اس لیے کوئی موازنہ نہیں کیا گیا۔ حقیقی download میں اس کی عام وجہ working directory ہوتی ہے، کیونکہ فہرست میں موجود نام اس directory کے لحاظ سے relative ہوتے ہیں جہاں سے آپ command چلاتے ہیں۔ اس directory میں جائیں جس میں فائل موجود ہے، پھر command دوبارہ چلائیں۔ صرف اپنی موجودہ فائلوں کی جانچ کرنے کے لیے یہ اختیار دیں:

sha256sum --ignore-missing -c SHA256SUMS.all

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

شائع شدہ digest کو آنکھ سے پڑھے بغیر paste کریں

64 hexadecimal حروف کا آنکھ سے موازنہ کرنا وہ مرحلہ ہے جہاں یہ عادت واقعی ناکام ہوتی ہے۔ لوگ پہلے 4 حروف اور آخری 4 حروف دیکھ کر اسے match قرار دے دیتے ہیں، اور ایک پُرعزم attacker عین اسی موازنے کی توقع کرتا ہے۔ موازنہ tool کو کرنے دیں۔ EXPECTED کو publisher سے copy کیے گئے digest پر set کریں۔ اس کے لیے 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 کے درمیان 2 spaces ہیں، اسی لیے format string میں 2 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 اس trailing character کو نظرانداز کرتا ہے اور پھر بھی OK print کرتا ہے۔ اس لیے CRLF list آپ کے check کے ناکام ہونے کی وجہ نہیں، اگرچہ coreutils سے باہر کے tools اسے اتنی آسانی سے قبول نہیں کرتے۔ اپنی محفوظ copy کو tr -d '\r' < SHA256SUMS > SHA256SUMS.clean کے ساتھ normalise کریں۔

Checksum کیا ثابت کرتا ہے، اور کیا ثابت نہیں کرتا؟

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

یہ file کے مصنف کے بارے میں کچھ ثابت نہیں کرتا۔ Digest bytes کے بارے میں ایک حقیقت ہے، لوگوں کے بارے میں نہیں۔ اگر ایک ہی page file اور digest دونوں فراہم کرتا ہے، تو جو شخص ایک کو تبدیل کر سکتا ہے وہ دوسرے کو بھی تبدیل کر سکتا ہے، اور آپ کی OK line صرف یہ بتاتی ہے کہ mirror اپنے ہی مواد سے مطابقت رکھتا ہے۔ اس لیے یہ اصول checksum چلانے کو مفید بناتا ہے: digest اس جگہ کے علاوہ کسی دوسری جگہ سے حاصل کریں جہاں سے file حاصل کی تھی۔ مثلاً image کسی mirror یا torrent سے حاصل کریں، لیکن digest project کے اپنے domain سے TLS (transport layer security) کے ذریعے لیں۔ اب حملہ آور کو ایک کے بجائے دو جگہوں کا اختیار حاصل کرنا ہوگا۔ یہ بھی کچھ نہیں بتاتا کہ تصدیق شدہ bytes چلانے کے بعد کیا کریں گے۔ یہ ہر اس چیز کے بارے میں الگ سے پوچھنے کے قابل سوال ہے جو آپ کی جانب سے 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 میں شائع ہو چکا ہے۔ ایک MD5SUMS file پھر بھی truncated download کو شناخت کر لیتی ہے، کیونکہ random corruption کوئی crafted collision نہیں ہوتی۔ لیکن یہ ایسے شخص کو نہیں روک سکتی جو آپ کو دھوکا دینے کی کوشش کر رہا ہو۔ جب project دونوں شائع کرے تو SHA-256 line استعمال کریں۔

جب signatures کا کردار شروع ہوتا ہے

signature اس خلا کو پُر کر دیتی ہے جو digest چھوڑ دیتا ہے۔ publisher، private key کے ذریعے digest file پر دستخط کرتا ہے، اور آپ اسے اس کی public key سے جانچتے ہیں: gpg --verify SHA256SUMS.asc SHA256SUMS۔ اگر یہ verification کامیاب ہو جائے تو digests کی فہرست اسی شخص یا ادارے سے آئی ہے جس کے پاس وہ 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 کا مطلب ہے کہ ریاضیاتی verification درست ہے۔ اس کا مطلب یہ نہیں کہ key اسی project سے تعلق رکھتی ہے جسے آپ سمجھ رہے ہیں۔ fingerprint کسی دوسرے source سے حاصل کریں، مثلاً مختلف domain پر موجود project کی documentation سے یا کسی ایسے distribution package سے جو پہلے ہی یہ key فراہم کرتا ہو، اور آخری 8 characters کے بجائے مکمل fingerprint کا موازنہ کریں۔ یہی احتیاط SSH private key کے لیے بھی ضروری ہے، اسی وجہ سے: key ہی اعتماد کا فیصلہ کرتی ہے، اور اس کے بعد آنے والا پورا chain اسی اعتماد کو اختیار کرتا ہے۔

Reproducible builds اس تصور کو ایک قدم آگے لے جاتی ہیں۔ شائع شدہ digest اب بھی آپ کو اس binary سے وابستہ کرتا ہے جسے ایک machine نے build کیا ہو۔ جب کسی project کا build reproducible ہو تو کوئی بھی شخص اسی source کو compile کر کے بالکل یکساں bytes پر مشتمل output حاصل کر سکتا ہے۔ اس طرح آزاد builders شائع شدہ digest کی تصدیق کر سکتے ہیں، بجائے اس کے کہ آپ سے ایک server کی بات پر بھروسا کرنے کو کہا جائے۔ یہ اہمیت ہر سال بڑھ رہی ہے، کیونکہ زیادہ code خودکار pipelines اور machine-written patches کے ذریعے آ رہا ہے۔ Build میں شامل کیے جانے والے code کی منظوری دینا 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 اس کی اطلاع دیتا ہے: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY اس وقت جب third-party repository کی key موجود نہ ہو، یا Hash Sum mismatch اس وقت جب fetch کیا گیا index signed Release سے مطابقت نہ رکھتا ہو۔ عموماً اس کا مطلب ہوتا ہے کہ caching proxy نے پرانی file فراہم کی ہے یا mirror کی synchronization ابھی مکمل نہیں ہوئی تھی۔

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

ہاتھ سے نصب کی جانے والی اشیا کے لیے digests کی فہرست رکھیں

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

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 سے تصدیق کرتا ہے۔ scheduled job میں یہی شکل استعمال کریں۔ --status اس سے بھی آگے جاتا ہے اور بالکل کچھ 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 کو اتنی آسانی سے rewrite کر سکتا ہے جتنی آسانی سے اس نے binary کو rewrite کیا تھا۔ اگر آپ چاہتے ہیں کہ یہ list قابلِ اعتماد ہو تو اسے machine سے باہر رکھیں۔ یہ اس وسیع تر سوال کا بھی حصہ ہے کہ آپ واقعی VPS پر کس حد تک اعتماد کر رہے ہیں اور اس کے نیچے موجود disk تک مزید کون پہنچ سکتا ہے۔

FAQ

کیا مطابقت رکھنے والا checksum یہ ثابت کرتا ہے کہ download محفوظ ہے؟

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

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

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

کیا download verify کرنے کے لیے MD5 کافی ہے؟

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

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

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

کسی web page پر دیے گئے digest کے خلاف ایک file کی جانچ کیسے کروں؟

characters کا آنکھ سے موازنہ نہ کریں۔ digest اور file name کو دو spaces سے جدا کر کے ایک ہی line میں محفوظ کریں، پھر اس file کے خلاف sha256sum -c چلائیں اور اس کے دکھائے گئے OK یا FAILED کو پڑھیں۔ printf '%s %s\n' سے line بنانا formatting کی ان غلطیوں سے بچاتا ہے جن کی وجہ سے sha256sum file کو no properly formatted checksum lines found کے ساتھ مسترد کر دیتا ہے۔