Linuxలో checksumతో downloadsను ఎలా ధృవీకరించాలి

checksum తో download ను రెండు నిమిషాల్లో ధృవీకరించండి

checksum తో download ను ధృవీకరించడానికి, అందుకున్న file కు hash లెక్కించి, ఆ hash ను publisher ఇచ్చిన hash తో tool పోల్చేలా చేయండి. sha256sum ఈ రెండు పనులను చేస్తుంది: స్వతంత్రంగా ఉపయోగిస్తే digest ను చూపిస్తుంది; -c తో ఉపయోగిస్తే digest ల జాబితాను చదివి, ఏ files సరిపోతున్నాయో నివేదిస్తుంది. మీరు సృష్టించే file పై ఈ మొత్తం ప్రక్రియను ఈ guide అమలు చేస్తుంది. తరువాత ఆ file ను ఉద్దేశపూర్వకంగా మార్చి, failure ఎలా జరుగుతుందో ప్రత్యక్షంగా చూడేలా చేస్తుంది.

ఈ మొత్తం ప్రక్రియలో ఒక విషయాన్ని గుర్తుంచుకోండి. checksum ద్వారా మీ వద్ద ఉన్న bytes, digest ను రూపొందించిన bytes అవేనా అనేది తెలుస్తుంది. అయితే వాటిని ఎవరు రూపొందించారో checksum ద్వారా తెలియదు. ఆ రెండవ ప్రశ్నకు signature మరియు మీరు విశ్వసించే key అవసరం. ఈ guide చివరి భాగంలో ఈ రెండింటి మధ్య ఉన్న పరిమితి ఎక్కడో స్పష్టంగా చూపిస్తుంది.

అభ్యాసం కోసం ఒక ఫైల్‌ను సృష్టించండి

ఏదీ సిస్టమ్‌లోని ఇతర భాగాలను ప్రభావితం చేయకుండా scratch directory లో పని చేయండి. క్రింది ప్రతి 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

మీకు ఒక line కనిపిస్తుంది: 64 hexadecimal characters, రెండు spaces, ఆ తర్వాత file name. ఆ 64 characters file యొక్క digest. అదే command ను మళ్లీ run చేస్తే line మారదు, ఎందుకంటే hashing deterministic: ఒకే input ఎల్లప్పుడూ ఒకే output ను ఇస్తుంది. File లోని ఒక character ను మార్చి మళ్లీ run చేస్తే digest కొద్దిగా మాత్రమే మారదు. అది పూర్తిగా భిన్నంగా కనిపిస్తుంది, ఎందుకంటే ఒక input bit మారితే output bits లో సుమారు సగం మారుతుంది. ఈ లక్షణం వల్ల 64-character string ను 4 GB image కు ఉపయోగించగల stand-in గా ఉపయోగించవచ్చు.

SHA256SUMS ఫైల్‌ను భద్రపరచి, తరువాత దాన్ని తనిఖీ చేయండి

స్క్రీన్‌పై కనిపించే digest ఒక రోజు తరువాత ఉపయోగపడదు. దాన్ని ఒక ఫైల్‌లో రాయండి. sha256sum స్వయంగా ఉపయోగించే format లోనే రాయండి, తద్వారా tool దాన్ని తరువాత మళ్లీ చదవగలదు.

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

sha256sum -c జాబితాలోని ప్రతి line ను చదివి, ఆ line లో పేర్కొన్న file ను hash చేసి, రెండు digestలను పోల్చుతుంది. విజయవంతమైన run ప్రతి file కు ఒక line ను ముద్రిస్తుంది:

payload.txt: OK

Exit status ను కూడా తనిఖీ చేయండి. ఎందుకంటే script ఆ విలువను చదువుతుంది; text ను ఎప్పుడూ చదవదు. విజయవంతమైన run తర్వాత echo $?, 0 ను ముద్రిస్తుంది. SHA256SUMS అనే పేరు ఒక convention మాత్రమే, తప్పనిసరి నియమం కాదు. అయితే distributions మరియు చాలా release pages దీనినే ఉపయోగిస్తాయి. కాబట్టి మీరు కూడా ఇదే పేరును ఉపయోగించండి. అప్పుడు file తెరవకుండానే అందులో ఏముందో తరువాతి వ్యక్తికి తెలుస్తుంది.

ఒక byte మార్చి తనిఖీ విఫలమవడాన్ని గమనించండి

ఇప్పుడు ఉద్దేశపూర్వకంగా ఫైల్‌ను మార్చండి. ఇది offset 5 వద్ద ఒక byte మాత్రమే రాస్తుంది. మిగతా మొత్తం అలాగే ఉంటుంది. అందువల్ల ఫైల్ పొడవు మరియు పేరు మారవు.

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

ఇక్కడ ముఖ్యమైన flag conv=notrunc. ఇది లేకపోతే, 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

ఇదే మొత్తం విధానం. ఫైల్‌లో ఎక్కడైనా ఒక byte తేడా ఉన్నా FAILED వస్తుంది. కనెక్షన్ తెగిపోవడం వల్ల మధ్యలో ఆగిపోయిన download, నిన్నటి build ను అందించే mirror, transit సమయంలో ఫైల్‌ను మార్చిన proxy, తప్పు block ను తిరిగి ఇచ్చిన disk — ఇవన్నీ అదే ఫలితానికి దారితీస్తాయి.

జాబితాలో మీరు download చేయని file పేరు ఉన్నప్పుడు

నిజమైన SHA256SUMS file లో project విడుదల చేసే ప్రతి 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 అసలు లభించలేదు. అందువల్ల ఏదీ compare కాలేదు. నిజమైన download లో సాధారణ కారణం working directory. ఎందుకంటే జాబితాలోని పేర్లు మీరు command run చేసే directory కి relative గా ఉంటాయి. File ఉన్న directory కి మారి command ను మళ్లీ run చేయండి. ప్రస్తుతం మీ వద్ద ఉన్న files ను మాత్రమే తనిఖీ చేయాలంటే, దాన్ని అలా అడగండి:

sha256sum --ignore-missing -c SHA256SUMS.all

ఇది payload.txt: OK ను print చేసి 0 తో exit అవుతుంది. జాబితాలో ఉన్న పేర్లలో ఏదీ లేకపోతే, --ignore-missing సున్నా files పై మౌనంగా విజయవంతం కాదు. అది no file was verified అని report చేసి non-zero తో exit అవుతుంది. ఇదే కావాల్సిన ప్రవర్తన. ఎందుకంటే ఏదీ తనిఖీ చేయని pass గుర్తించకుండా మిగిలిపోయే failure అవుతుంది.

కళ్లతో చదవకుండా ప్రచురించిన digest ను paste చేయడం

64 hexadecimal అక్షరాలను కళ్లతో పోల్చడం ఈ అలవాటు విఫలమయ్యే ప్రధాన కారణం. చాలామంది మొదటి నాలుగు అక్షరాలు, చివరి నాలుగు అక్షరాలు చూసి సరిపోలిందని నిర్ణయిస్తారు. పట్టుదలతో దాడి చేసే attacker కూడా ఇదే పోలికపై ఆధారపడతాడు. పోలికను tool‌కే అప్పగించండి. Publisher నుంచి copy చేసిన digest కు EXPECTED విలువను సెట్ చేయండి. ఇందుకోసం EXPECTED= తర్వాత paste చేసిన విలువను ఉంచి, -c ఆశించే ఒకే line ను తయారు చేయండి:

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

Digest మరియు file name మధ్య రెండు spaces ఉంటాయి. అందుకే format string లో కూడా రెండు spaces ఉంటాయి. ఇదే రూపాన్ని sha256sum రాస్తుంది, -c చదువుతుంది. Digest మాత్రమే ఉన్న file checksum line కాదు. అందువల్ల మీరు ఉద్దేశించిన file ఏదో ఊహించకుండా, check మొత్తం file ను no properly formatted checksum lines found తో reject చేస్తుంది. కొన్ని projects బదులుగా BSD tagged style ను publish చేస్తాయి: 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 చేయండి.

checksum ఏమి నిరూపిస్తుంది, ఏమి నిరూపించదు?

checksum ఒక విషయాన్ని నిరూపిస్తుంది: మీ diskలోని bytes, ప్రచురించిన digest ను ఉత్పత్తి చేసిన bytes తో సమానంగా ఉన్నాయని. ఇది అనుకోకుండా జరిగిన damage ను పూర్తిగా గుర్తిస్తుంది. Download mirror లో file ను మార్చినప్పటికీ, digest ప్రచురించిన page ను మార్చలేని నిర్లక్ష్య దాడిచేసేవారిని కూడా ఇది గుర్తిస్తుంది.

ఇది authorship గురించి ఏమీ నిరూపించదు. Digest అనేది bytes కు సంబంధించిన వాస్తవం, వ్యక్తులకు సంబంధించిన వాస్తవం కాదు. ఒకే page file మరియు digest రెండింటినీ అందిస్తే, ఒకదాన్ని మార్చగల వ్యక్తి మరొకదానినీ మార్చగలడు. అప్పుడు మీ OK line mirror తనతో తానే సరిపోలుతోందని మాత్రమే చూపిస్తుంది. అందుకే checksums అమలు చేయడం ఉపయోగకరంగా ఉండే నియమం ఇది: file తీసుకున్న ప్రదేశానికి భిన్నమైన ప్రదేశం నుంచి digest తీసుకోండి. ఉదాహరణకు, image ను mirror లేదా torrent నుంచి తీసుకున్నప్పుడు, TLS (transport layer security) ద్వారా project's own domain నుంచి digest తీసుకోండి. ఇప్పుడు దాడిచేసేవారు ఒక ప్రదేశం కాకుండా రెండు ప్రదేశాలను నియంత్రించాలి. మీరు ధృవీకరించిన bytes ను అమలు చేసిన తర్వాత అవి ఏమి చేస్తాయో దీనివల్ల తెలియదు. మీ తరఫున అమలయ్యే 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 అనేది రూపొందించిన collision కాదు. కానీ మిమ్మల్ని మోసం చేయడానికి ప్రయత్నిస్తున్న వ్యక్తిని ఇది ఆపలదు. Project రెండింటినీ ప్రచురించినప్పుడు SHA-256 line ను తీసుకోండి.

సంతకాలు తీసుకునే బాధ్యత

డైజెస్ట్ వదిలే లోటును సంతకం పూడుస్తుంది. ప్రచురణకర్త private key తో digest file పై సంతకం చేస్తారు. మీరు వారి public key తో దాన్ని తనిఖీ చేస్తారు: gpg --verify SHA256SUMS.asc SHA256SUMS. ఇది విజయవంతమైతే, digest ల జాబితా ఆ key ను కలిగి ఉన్న వ్యక్తి లేదా సంస్థ నుంచే వచ్చిందని అర్థం. తరువాత sha256sum -c SHA256SUMS మీ disk లోని file ను ఆ జాబితాతో సరిపోలుస్తుంది. ఇలా key నుంచి file లోని bytes వరకు విశ్వసనీయత గొలుసు కొనసాగుతుంది.

ఇప్పుడు బలహీనమైన స్థానం key అవుతుంది. 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 లేదా ఇప్పటికే ఆ key ను ship చేసే distribution package ను ఉపయోగించండి. చివరి ఎనిమిది characters కాకుండా పూర్తి fingerprint ను సరిపోల్చండి. ఇదే కారణంతో SSH private key కు అవసరమైన జాగ్రత్త కూడా ఇక్కడ వర్తిస్తుంది: key ఆధారంగానే trust నిర్ణయం తీసుకుంటారు. దాని తర్వాతి మొత్తం ప్రక్రియ ఆ నిర్ణయాన్ని అనుసరిస్తుంది.

Reproducible builds ఈ ఆలోచనను మరో దశ ముందుకు తీసుకెళ్తాయి. ప్రచురించిన digest తోనూ, ఒక machine build చేసిన binary పైనే మీరు ఆధారపడతారు. Project build reproducible గా ఉంటే, ఎవరైనా అదే source ను compile చేసి byte-identical output పొందవచ్చు. అందువల్ల independent builders ప్రచురించిన digest ను స్వతంత్రంగా నిర్ధారించగలరు. ఒక server చెప్పినదాన్ని మాత్రమే నమ్మాల్సిన అవసరం ఉండదు. Automated pipelines ద్వారా మరింత code వస్తున్న కొద్దీ, machine-written patches కూడా పెరుగుతున్నందున ఇది ప్రతి సంవత్సరం మరింత ప్రాముఖ్యం పొందుతోంది. Build లోకి ఏదిని అంగీకరించాలో నిర్ణయించడం policy ప్రశ్న. AI-assisted code కోసం open source policies కూడా ఇదే supply chain పై వ్యతిరేక దిశ నుంచి పనిచేస్తాయి.

మీ ప్యాకేజీ మేనేజర్ ఇప్పటికే ఈ పని మీ కోసం చేస్తుంది

Debian మరియు Ubuntuలో, ఇన్‌స్టాలేషన్‌ సమయంలో అడగకుండానే apt ప్రతి సారి ఈ ప్రక్రియను అమలు చేస్తుంది. ప్యాకేజీ indexలో ప్రతి .deb ఫైల్‌కు SHA-256 digest ఉంటుంది. ఆ index ఫైళ్ల digestలను Release ఫైల్ కలిగి ఉంటుంది. 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 మధ్యలో ఉండటం దీనికి కారణం.

ప్రాజెక్ట్ home pageలో curl నుంచి scriptను నేరుగా shellకు pipe చేయమని చెప్పినప్పుడు, దాన్ని అంచనా వేయడానికి ఇదే ప్రమాణం. ఏదీ bytesను verify చేయదు. మీరు వాటిని చూడలేరు. Server ఒక scriptకు ఒక contentను, browserకు మరో contentను కూడా పంపగలదు. తరువాత పరిశీలించడానికి మీ వద్ద copy కూడా ఉండదు. curl -fsSL <url> -o install.sh తో fileకు download చేసి, దాని hashను లెక్కించండి. less తో దాన్ని చదివిన తరువాత మాత్రమే run చేయండి. ఈ అలవాటుకు సుమారు ఇరవై seconds పడుతుంది. Boxలో మరేదీ install చేయకముందే, మొదటి పది నిమిషాల్లో కొత్త VPSలో ప్రారంభించాల్సిన అలవాటు ఇదే.

మీ చేతితో ఇన్‌స్టాల్ చేసిన వాటి కోసం digestల జాబితాను ఉంచండి

apt ద్వారా ఇన్‌స్టాల్ చేసిన packages ట్రాక్ చేయబడతాయి. మీరు /usr/local/bin లోకి కాపీ చేసిన binary ట్రాక్ చేయబడదు; దాన్ని సిస్టమ్‌లో ఏదీ పర్యవేక్షించదు. Digestల జాబితా ఉంటే, దాన్ని అవసరమైనప్పుడు తనిఖీ చేయవచ్చు:

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

ప్రతి file సరిపోలితే --quiet ఏమీ ప్రింట్ చేయదు. కొన్ని సరిపోలకపోతే విఫలమైన వాటికి సంబంధించిన lines మాత్రమే ప్రింట్ చేస్తుంది. అందువల్ల నిశ్శబ్ద output pass ను సూచిస్తుంది, మరియు echo $? దాన్ని 0 తో నిర్ధారిస్తుంది. Scheduled job లో ఉపయోగించాల్సిన రూపం ఇదే. --status ఇంకా ముందుకు వెళ్లి ఏ outputనూ ప్రింట్ చేయదు; మీకు exit status మాత్రమే మిగులుతుంది. sha256sum /usr/local/bin/* > ~/local-bin.sha256 తో ఇదే నమూనాను వాస్తవ files కు వర్తింపజేస్తే baseline సిద్ధమవుతుంది. Paths ను మీరు టైప్ చేసిన విధంగానే జాబితాలో నిల్వ చేస్తుంది. అందువల్ల absolute paths ఉపయోగిస్తే ఏ directory నుంచైనా check పనిచేస్తుంది.

ఆ baseline విలువ ఏమిటో స్పష్టంగా అర్థం చేసుకోండి. ఇది మారిన file ను గుర్తిస్తుంది. ఇప్పటికే root ప్రాప్యత కలిగిన attacker ను ఇది గుర్తించదు, ఎందుకంటే ఆ attacker binaryను మార్చినంత సులభంగా inventory.sha256 ను కూడా తిరిగి రాయగలడు. ఈ జాబితా ఉపయోగకరంగా ఉండాలంటే దాన్ని machine వెలుపల ఉంచండి. మీరు నిజంగా ఎంతవరకు VPS ను విశ్వసిస్తున్నారో, దాని కింద ఉన్న diskను ఇంకెవరు చేరుకోగలరో అనే విస్తృత ప్రశ్నలో ఇది కూడా భాగమే: మీరు VPS ను నిజంగా ఎంతవరకు విశ్వసిస్తున్నారు.

FAQ

సరిపోలిన checksum అంటే download సురక్షితమని అర్థమా?

కాదు. మీరు కలిగి ఉన్న bytes, మీరు పోల్చిన digest కు సరిపోతున్నాయని మాత్రమే అర్థం. ఆ digest ను ప్రచురించిన page పై attacker నియంత్రణ కలిగి ఉంటే, అతను తన file యొక్క digest ను ప్రచురిస్తాడు. అప్పుడు మీ check OK ను చూపిస్తుంది. సరిపోలిక అనేది consistency గురించి మాత్రమే చెబుతుంది. భద్రతను నిర్ధారించాలంటే, వేరే source నుంచి పొందిన key తో signature ను verify చేయాలి. అప్పుడే ఆ digest కు ఆ విశ్వసనీయత వర్తిస్తుంది.

sha256sum -c FAILED open or read ను ఎందుకు చూపిస్తుంది?

ఎందుకంటే అది file ను చదవలేదు. దాని పైన ఉన్న ప్రత్యేక line, అది వెతికిన పేరు No such file or directory అని చెబుతుంది. SHA256SUMS file లోని పేర్లు, మీరు command నడిపే directory కి relative గా ఉంటాయి. అందువల్ల download ఉన్న directory లోకి మారి command ను మళ్లీ నడపండి. ఆ list లో మీరు download చేయని files కూడా ఉంటే, --ignore-missing ను జోడించండి. open or read లేకుండా ఉన్న సాధారణ FAILED దీనికి వ్యతిరేక పరిస్థితిని సూచిస్తుంది: file చదవబడింది, కానీ దాని digest సరిపోలలేదు.

Download ను verify చేయడానికి MD5 సరిపోతుందా?

అనుకోకుండా జరిగిన నష్టం కోసం అవును. మధ్యలో truncated అయిన transfer లేదా చెడిపోయిన disk block వల్ల యాదృచ్ఛికంగా సరిపోలే 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 ను కలిగి ఉన్న వ్యక్తి ద్వారా signed అయిందని నిరూపిస్తుంది. ఇవి వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి. Project రెండింటినీ అందిస్తే రెండింటినీ run చేయండి. Signature digest list ను విశ్వసించదగినదిగా చేస్తుంది. తరువాత digest list download చేసిన file ను విశ్వసించదగినదిగా చేస్తుంది.

Web page లో ముద్రించిన digest తో ఒక file ను ఎలా check చేయాలి?

అక్షరాలను చూసి పోల్చవద్దు. Digest మరియు file name ను ఒకే line లో, రెండు spaces తో వేరు చేసి save చేయండి. తరువాత ఆ file పై sha256sum -c ను run చేసి, అది చూపించే OK లేదా FAILED ను పరిశీలించండి. printf '%s %s\n' తో line ను రూపొందిస్తే, formatting లో జరిగే తప్పులు నివారించవచ్చు. అలాంటి తప్పుల వల్ల sha256sum file ను no properly formatted checksum lines found తో reject చేస్తుంది.