Paano mag-verify ng download gamit ang checksum sa Linux

Mag-verify ng download gamit ang checksum sa loob ng dalawang minuto

Para mag-verify ng download gamit ang checksum, i-hash ang natanggap mong file at hayaang ikumpara ng isang tool ang hash na iyon sa hash na inilathala ng publisher. Ginagawa ng sha256sum ang dalawang bahaging ito: kapag ginamit nang mag-isa, nagpi-print ito ng digest; kapag ginamit kasama ng -c, nagbabasa ito ng listahan ng mga digest at nag-uulat kung aling mga file ang tumutugma. Gagamitin ng gabay na ito ang buong proseso sa isang file na ikaw ang gagawa, pagkatapos ay sadyang babaguhin ang file para makita mo mismo kung paano lumilitaw ang failure sa halip na basahin lamang ang tungkol dito.

Tandaan ang isang pangungusap na ito sa buong proseso. Sinasabi ng checksum kung ang mga byte na hawak mo ay ang mga byte na gumawa sa digest, pero wala itong sinasabi tungkol sa kung sino ang gumawa ng mga iyon. Kailangan ng signature at key na pinagkakatiwalaan mo para masagot ang ikalawang tanong. Sa huling bahagi ng gabay na ito, malinaw na ipapakita kung saan naghihiwalay ang dalawang ito.

Gumawa ng file para pagpraktisan

Magtrabaho sa isang scratch directory para walang anumang bahagi rito ang makaapekto sa ibang bahagi ng system. Ang bawat command sa ibaba ay mula sa GNU coreutils, ang pangunahing command set na kasama sa anumang Ubuntu o Debian server, kaya walang kailangang i-install.

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

Makakakuha ka ng isang linya: 64 hexadecimal character, dalawang space, at pagkatapos ay ang file name. Ang 64 character na iyon ang digest ng file. Patakbuhin muli ang command at magiging kapareho ang linya, dahil deterministic ang hashing: pareho ang output para sa parehong input. Baguhin ang isang character ng file at patakbuhin itong muli. Hindi bahagyang magbabago ang digest. Magmumukha itong lubos na naiiba, dahil kapag nagbago ang isang input bit, humigit-kumulang kalahati ng output bits ang nagbabago. Dahil sa property na ito, nagagamit ang 64-character string bilang kinatawan ng isang 4 GB image.

Mag-save ng SHA256SUMS file, pagkatapos ay i-check ito

Walang silbi ang digest na nasa screen makalipas ang isang araw. Isulat ito sa isang file sa format na mismong ginagamit ng sha256sum para mabasa itong muli ng tool sa susunod.

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

Binabasa ng sha256sum -c ang bawat linya ng listahan, hina-hash ang file na nakapangalan sa linyang iyon, at ikinukumpara ang dalawang digest. Sa matagumpay na pagtakbo, isang linya ang inilalabas para sa bawat file:

payload.txt: OK

I-check din ang exit status, dahil iyon ang binabasa ng script at hindi ang text. Inilalabas ng echo $? ang 0 pagkatapos ng malinis na pagtakbo. Convention ang pangalang SHA256SUMS at hindi ito mahigpit na panuntunan, pero ginagamit ito ng mga distribution at karamihan ng release page. Gamitin din ito para malaman agad ng susunod na tao kung ano ang laman ng file nang hindi ito kailangang buksan.

Baguhin ang isang byte at obserbahan ang pag-fail ng check

Ngayon, sadyang sirain ang file. Isusulat nito ang isang byte sa offset 5 at iiwanang hindi nagbabago ang lahat ng iba pa, kaya mananatili ang haba at pangalan ng file.

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

conv=notrunc ang mahalagang flag: kung wala ito, ita-truncate ng dd ang file sa puntong paghinto nito sa pagsusulat, at mas halatang uri ng pagkasira ang sinusuri mo. Ipinapakita ngayon ng check ang:

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

Ipinapakita ng echo $? ang 1. Nangangahulugan ang FAILED na nabasa ang file at hindi tumugma ang digest nito sa nasa listahan. Ibalik ang orihinal na bytes at kumpirmahing bumalik sa OK ang resulta ng check:

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

Iyon ang buong nakagawiang proseso. Ang pagkakaiba ng isang byte, saanman sa file, ay nagreresulta sa FAILED. Isang download na naputol dahil sa nawalang koneksyon, mirror na naghahatid ng build mula kahapon, proxy na muling sumulat sa file habang ipinapadala ito, o disk na nagbalik ng masamang block: lahat ng ito ay hahantong sa parehong linyang iyon.

Kapag may binabanggit na file ang listahan na hindi mo na-download

Ang aktuwal na SHA256SUMS file mula sa isang distribution ay naglilista ng bawat image na inilabas ng proyekto, at isa sa mga ito ang na-download mo. Gawin natin dito ang sitwasyong iyon.

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

Ibang failure ang FAILED open or read kaysa sa FAILED, at nakasasayang ng oras ang pagkakalito sa dalawa. Ibig sabihin ng FAILED ay mali ang bytes. Ibig sabihin ng FAILED open or read ay hindi kailanman nakuha ng sha256sum ang file, kaya walang ikinumpara. Sa aktuwal na download, karaniwang sanhi nito ang working directory, dahil relative ang mga pangalan sa listahan sa lokasyon kung saan mo pinatakbo ang command. Lumipat sa directory na naglalaman ng file at patakbuhin itong muli. Para suriin lamang ang mga file na mayroon ka, gamitin ito:

sha256sum --ignore-missing -c SHA256SUMS.all

Ipinapakita nito ang payload.txt: OK at nag-e-exit sa 0. Kung wala sa mga pangalang nasa listahan ang naroroon, hindi tahimik na nagtatagumpay ang --ignore-missing kapag zero file ang nasuri. Iniuulat nito na no file was verified at nag-e-exit na non-zero. Ito ang tamang behavior, dahil ang pass na walang nasuring anuman ay isang failure na hindi mo mapapansin.

Suriin ang na-publish na digest nang hindi ito binabasa nang mano-mano

Dito tunay na pumapalya ang ganitong gawi: kapag mano-manong ikinukumpara ang 64 hexadecimal character. Sinusuri ng mga tao ang unang apat na character at huling apat, saka tinatawag itong tugma. Iyan mismo ang paghahambing na inaasahan ng isang determinadong attacker. Hayaan ang tool ang magkumpara. Itakda ang EXPECTED sa digest na kinopya mo mula sa publisher. Gamitin ang EXPECTED= na sinusundan ng nakopyang value, saka buuin ang iisang linyang inaasahan ng -c:

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

May dalawang space sa pagitan ng digest at file name. Iyan ang dahilan kung bakit dalawang space ang nasa format string. Iyan ang format na isinusulat ng sha256sum at binabasa ng -c. Ang file na digest lamang ang laman ay hindi checksum line. Dahil dito, tinatanggihan ng check ang buong file gamit ang no properly formatted checksum lines found sa halip na hulaan kung aling file ang tinutukoy mo. BSD tagged style naman ang inilalathala ng ilang project, kung saan SHA256 (payload.txt) = ang sinusundan ng digest. Isinusulat ng GNU coreutils ang format na iyon gamit ang sha256sum --tag payload.txt at binabasa ito gamit ang -c, kaya maaaring i-save ang alinman sa dalawang format.

Kapag kakaiba ang gawi ng check, tingnan ang mismong list gamit ang cat -A SHA256SUMS. Minamarkahan nito ang dulo ng bawat linya gamit ang $ at ipinapakita ang mga character na hindi mo karaniwang nakikita. Ang linyang nagtatapos sa ^M$ ay maaaring may carriage return na nakuha mula sa Windows editor. Binabalewala ng GNU sha256sum ang trailing character na iyon at nagpi-print pa rin ng OK. Ibig sabihin, hindi ang CRLF list ang sumisira sa check, bagama't hindi gaanong mapagparaya rito ang mga tool sa labas ng coreutils. I-normalize ang kopyang itatago mo gamit ang tr -d '\r' < SHA256SUMS > SHA256SUMS.clean.

Ano ang pinatutunayan ng checksum, at ano ang hindi nito pinatutunayan?

Isang bagay lang ang pinatutunayan ng checksum: ang mga byte sa iyong disk ay kapareho ng mga byte na gumawa sa inilathalang digest. Ganap nitong natutukoy ang aksidenteng pagkasira. Natutukoy din nito ang isang pabaya na attacker na nagpalit ng file sa download mirror pero hindi nakapagbago sa page na naglathala ng digest.

Wala itong pinatutunayan tungkol sa may-akda. Ang digest ay impormasyon tungkol sa mga byte, hindi tungkol sa mga tao. Kung iisang page ang naghahatid ng file at digest, maaaring baguhin ng sinumang makapagbago sa isa ang kapwa nito. Sa ganitong sitwasyon, ang iyong OK line ay nangangahulugan lang na tugma ang mirror sa sarili nito. Kaya ito ang tuntuning nagpapahalaga sa pagpapatakbo ng checksums: kunin ang digest mula sa ibang lugar kaysa sa pinanggalingan ng file. Halimbawa, kunin ito sa sariling domain ng proyekto gamit ang TLS (transport layer security), habang ang image ay nagmula sa mirror o torrent. Ngayon, kailangang kontrolin ng attacker ang dalawang lugar sa halip na isa. Wala rin itong sinasabi tungkol sa gagawin ng mga na-verify na byte kapag pinatakbo mo ang mga ito. Hiwalay na tanong ito na dapat itanong sa anumang nag-e-execute para sa iyo, mula sa install script hanggang sa dsh plugin na tumatakbo gamit ang mga permission ng iyong agent.

Mahalaga rin ang algorithm. Ang SHA-256 (secure hash algorithm, 256-bit output) ay walang kilalang collision hanggang Agosto 2026, kaya ito ang ginagamit ng mga publisher. Hindi sapat ang MD5 (message digest 5) at SHA-1: maaaring gumawa ng dalawang magkaibang file na may parehong MD5 digest mula pa noong 2004, at isang chosen-prefix SHA-1 collision ang inilathala noong 2020. Nakakahuli pa rin ang isang MD5SUMS file ng truncated download, dahil ang random corruption ay hindi crafted collision. Hindi nito mapipigilan ang isang taong nagtatangkang linlangin ka. Kapag parehong inilathala ng proyekto ang mga ito, gamitin ang SHA-256 line.

Kapag mga lagda na ang ginagamit

Isinasara ng isang signature ang puwang na iniiwan ng isang digest. Sini-sign ng publisher ang digest file gamit ang private key, at ive-verify mo ito gamit ang kanilang public key: gpg --verify SHA256SUMS.asc SHA256SUMS. Kapag nagtagumpay ito, ang listahan ng mga digest ay nagmula sa may hawak ng key na iyon. Pagkatapos, iniuugnay ng sha256sum -c SHA256SUMS ang file sa iyong disk sa listahan, kaya ang chain ay umaabot mula sa key hanggang sa mismong bytes.

Napupunta ang mahinang bahagi sa key. Kapag kinuha mo ang key mula sa parehong page na naghatid ng file, naibibigay mo sa attacker ang dalawang bahaging kailangan niya. Tapat dito ang GnuPG, at sa unang verification ay ipinapakita nito ang Good signature kasama ang WARNING: This key is not certified with a trusted signature!. Ibig sabihin ng Good signature ay tama ang mathematics. Hindi nito ibig sabihin na ang key ay pagmamay-ari ng project na nasa isip mo. Kunin ang fingerprint mula sa ikalawang source, gaya ng documentation ng project sa ibang domain o distribution package na kasama na ang key, at ihambing ang buong fingerprint sa halip na ang huling walong character. Ito ang parehong pag-iingat na kailangan ng isang SSH private key, dahil pareho ang dahilan: ang key ang batayan ng tiwala, at minamana ito ng lahat ng kasunod na hakbang.

Isang hakbang pa ang ginagawa ng reproducible builds sa ideyang ito. Iniuugnay ka pa rin ng isang published digest sa binary na ginawa ng isang machine. Kapag reproducible ang build ng isang project, maaaring i-compile ng sinuman ang parehong source at makakuha ng output na magkapareho hanggang sa bawat byte. Dahil dito, makukumpirma ng mga independent builder ang published digest sa halip na hingin sa iyo na magtiwala sa sinabi ng isang server. Mas mahalaga ito bawat taon habang mas maraming code ang dumarating sa pamamagitan ng automated pipeline at mga patch na isinulat ng machine. Patakaran ang tanong kung ano ang tatanggapin mo sa isang build, at ang mga open source policy para sa code na tinulungan ng AI ay tumitingin sa parehong supply chain mula sa kabilang panig.

Ginagawa na ito ng package manager para sa iyo

Sa Debian at Ubuntu, awtomatikong pinapatakbo ng apt ang chain na ito sa bawat install. May SHA-256 digest ang package index para sa bawat .deb file. Nasa Release file ang mga digest ng mga index file na iyon, at may signature sa InRelease para sa Release, na sinusuri laban sa mga key sa /usr/share/keyrings at /etc/apt/trusted.gpg.d. Kapag naputol ang chain, ipinapaalam ito ng apt: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY kapag nawawala ang key ng third-party repository, o Hash Sum mismatch kapag hindi tumugma ang index na na-download mo sa signed na Release. Karaniwan itong nangangahulugang naghatid ang caching proxy ng lumang file o naabutan mo ang mirror habang nagsi-sync.

Ito ang pamantayang dapat gamitin kapag sinasabi ng home page ng isang project na i-pipe ang script mula sa curl diretso sa shell. Walang nagbe-verify sa bytes at hindi mo nakikita ang script. Maaari ring magbalik ang server ng isang resulta sa script at ibang resulta sa browser, at wala kang kopyang masusuri pagkatapos. I-download ito sa isang file gamit ang curl -fsSL <url> -o install.sh, i-hash ito, basahin ito gamit ang less, at saka lamang patakbuhin. Humigit-kumulang dalawampung segundo lang ang kailangan sa prosesong ito. Ito rin ang ugaling dapat mong simulan sa bagong VPS sa unang sampung minuto nito, bago mag-install ng anuman sa server.

Panatilihin ang listahan ng digests para sa mga manu-mano mong ini-install

Natatala ang mga package na ini-install ng apt. Hindi natatala ang binary na kinopya mo sa /usr/local/bin, at walang nagmo-monitor dito sa system. Ginagawang masusuri kapag kinakailangan ng digest list ang sitwasyong ito:

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

Walang inilalabas na output ang --quiet kapag tugma ang bawat file. Kapag may hindi tugma, ang mga linyang nabigo lamang ang inilalabas nito. Ibig sabihin, ang kawalan ng output ang pumapasa sa check, at kinukumpirma ito ng echo $? gamit ang 0. Ito ang format na dapat ilagay sa scheduled job. Mas mahigpit ang --status at wala talaga itong inilalabas na output; exit status lamang ang natitira. Gamitin ang parehong pattern sa aktuwal na mga file sa pamamagitan ng sha256sum /usr/local/bin/* > ~/local-bin.sha256 upang magkaroon ka ng baseline. Eksaktong gaya ng pag-type mo sa mga ito iniimbak ang mga path sa listahan, kaya gagana ang check mula sa anumang directory kapag absolute paths ang ginamit.

Dapat malinaw kung ano ang halaga ng baseline na ito. Nakikita nito kung may binagong file. Hindi nito nakikita ang attacker na mayroon nang root access, dahil kaya ng attacker na iyon na baguhin ang inventory.sha256 gaya ng pagpapalit nito sa binary. Itago ang listahan sa labas ng machine kung nais mong magkaroon ito ng tunay na silbi. Bahagi ito ng mas malawak na usapin kung gaano kalaki ang aktuwal mong pagtitiwala sa isang VPS at kung sino pa ang maaaring maka-access sa disk sa ilalim nito.

FAQ

Nangangahulugan ba na ligtas ang download kapag magkatugma ang checksum?

Hindi. Nangangahulugan lamang ito na tugma ang mga byte na mayroon ka sa digest na pinaghambingan mo. Kung kontrolado ng attacker ang page na nag-publish ng digest, maaari niyang i-publish ang digest ng sarili niyang file, at magpi-print ang iyong check ng OK. Pahayag lamang ng consistency ang isang match. Para makapagpahayag ng safety, kailangan ang signature na na-verify gamit ang key na nakuha mo mula sa ibang source. Saka lamang mamamana ng digest ang tiwalang iyon.

Bakit nagpi-print ang sha256sum -c ng FAILED open or read?

Dahil hindi nito nabasa ang file. May hiwalay na linya kaagad sa itaas nito na nagsasabing No such file or directory, kasama ang pangalan ng file na hinahanap nito. Relative sa directory kung saan mo pinapatakbo ang command ang mga pangalan sa loob ng SHA256SUMS file. Kaya pumunta sa directory na naglalaman ng download at patakbuhin itong muli. Kung may mga file ding nakalista na hindi mo na-download, idagdag ang --ignore-missing. Ang plain na FAILED na walang open or read ay kabaligtaran: nabasa ang file, ngunit hindi tugma ang digest nito.

Sapat na ba ang MD5 para i-verify ang download?

Para sa aksidenteng pagkasira, oo. Hindi basta-basta magreresulta sa magkatugmang MD5 digest ang naputol na transfer o masamang disk block. Laban sa attacker, hindi. Mula pa noong 2004, posible nang gumawa ng dalawang magkaibang file na may parehong MD5 digest, at nagkaroon ng chosen-prefix collision ang SHA-1 noong 2020. Gamitin ang SHA-256 line kapag parehong inilalathala ng project ang mga ito. Ituring naman ang MD5-only project bilang palatandaan ng lumang release process.

Ano ang pagkakaiba ng sha256sum -c at gpg --verify?

Pinatutunayan ng sha256sum -c na tugma ang isang file sa isang digest. Pinatutunayan naman ng gpg --verify na ang digest file ay nilagdaan ng may hawak ng isang partikular na private key. Magkaibang tanong ang sinasagot ng mga ito, kaya patakbuhin ang dalawa kapag parehong iniaalok ng project. Ginagawang mapagkakatiwalaan ng signature ang digest list, at ginagawang mapagkakatiwalaan naman ng digest list ang na-download na file.

Paano ko susuriin ang isang file gamit ang digest na naka-print sa isang web page?

Huwag ihambing ang mga character sa pamamagitan lamang ng tingin. I-save ang digest at pangalan ng file sa iisang linya, na pinaghihiwalay ng dalawang space. Pagkatapos, patakbuhin ang sha256sum -c laban sa file na iyon at basahin ang OK o FAILED na pini-print nito. Ang pagbuo ng linya gamit ang printf '%s %s\n' ay nakaiiwas sa mga formatting mistake na nagiging sanhi upang tanggihan ng sha256sum ang file gamit ang no properly formatted checksum lines found.