Paano I-verify ang Download Gamit ang Checksum sa Linux

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

Para i-verify ang download gamit ang checksum, i-hash ang file na natanggap mo at hayaan ang isang tool na ikumpara 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 iniuulat kung aling mga file ang tumutugma. Sa gabay na ito, isasagawa ang buong proseso sa isang file na ikaw ang gagawa, pagkatapos ay sadyang babaguhin ang file upang makita mo mismo kung paano lumilitaw ang failure sa halip na basahin lamang ang tungkol dito.

Isaisip ang isang pangungusap sa buong proseso. Sinasabi ng checksum kung ang mga byte na hawak mo ay ang mga byte na lumikha sa digest, ngunit wala itong sinasabi tungkol sa kung sino ang lumikha sa mga ito. Kailangan ng signature at pinagkakatiwalaang key para masagot ang ikalawang tanong. Ipinapakita ng huling bahagi ng gabay na ito kung saan eksaktong naghihiwalay ang dalawang ito.

Gumawa ng file para mapagpraktisan

Magtrabaho sa isang scratch directory para walang mabago sa ibang bahagi ng system. Ang bawat command sa ibaba ay mula sa GNU coreutils, ang pangunahing command set na karaniwang naroroon 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 na character na iyon ang digest ng file. Patakbuhin muli ang command at magiging magkapareho ang linya, dahil deterministic ang hashing: pareho ang output kapag pareho ang input. Baguhin ang isang character ng file at patakbuhin itong muli; hindi bahagyang magbabago ang digest. Magmumukha itong ganap na naiiba, dahil kapag nagbago ang isang input bit, humigit-kumulang kalahati ng output bits ang nagbabago. Dahil sa property na ito, maaaring gamitin ang 64-character string bilang kapalit ng 4 GB image.

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

Walang silbi ang digest na ipinapakita sa screen makalipas ang isang araw. Isulat ito sa isang file, gamit ang format na mismong isinusulat 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 nakasaad sa linyang iyon, at ikinukumpara ang dalawang digest. Sa matagumpay na run, isang linya ang ipinapakita para sa bawat file:

payload.txt: OK

Suriin din ang exit status, dahil iyon ang binabasa ng script at hindi ang text. Ipinapakita ng echo $? ang 0 pagkatapos ng malinis na run. Convention lamang ang pangalang SHA256SUMS at hindi ito requirement, pero ginagamit ito ng mga distribution at ng karamihan sa release page. Gamitin din ito para malaman agad ng susunod na tao kung ano ang laman ng file nang hindi na ito kailangang buksan.

Baligtarin ang isang byte at panoorin ang pagpalya ng check

Ngayon, sirain ang file nang sadya. Sumusulat ito ng isang byte sa offset 5 at hindi binabago ang iba, kaya nananatiling pareho 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

Ang conv=notrunc ang mahalagang flag: kung wala ito, ita-truncate ng dd ang file sa puntong itinigil nito ang pagsusulat, at mas halatang uri ng pagkasira ang masusuri mo. Ganito na ang output ng check:

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

Ini-print ng echo $? ang 1. Ibig sabihin ng FAILED, nabasa ang file pero hindi tumugma ang digest nito sa nasa listahan. Ibalik ang orihinal na bytes at kumpirmahing bumalik ang check sa OK:

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

Iyon ang buong routine. Ang isang byte na naiiba, saanman sa file, ay nagreresulta sa FAILED. Nagambala ang download dahil sa naputol na connection, naghatid ang mirror ng build kahapon, binago ng proxy ang file habang ipinapasa, o nagbalik ang disk ng maling block: lahat ng ito ay lalabas sa parehong linyang iyon.

Kapag may file sa listahan na hindi mo na-download

Ang totoong SHA256SUMS file mula sa isang distribution ay naglilista ng bawat image na nire-release ng project, at isa sa mga ito ang na-download mo. Gayahin ang sitwasyong iyon dito.

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 kumpara sa FAILED, at nakasasayang ng oras ang pagkalito sa mga ito. Ibig sabihin ng FAILED ay mali ang bytes. Ibig sabihin ng FAILED open or read ay hindi talaga nakuha ng sha256sum ang file, kaya walang naikumpara. Sa totoong download, ang karaniwang sanhi ay ang working directory, dahil relative sa directory kung saan mo pinapatakbo ang command ang mga pangalan sa listahan. Pumunta sa directory na naglalaman ng file at patakbuhin itong muli. Para ang aktuwal na mayroon ka lamang ang i-check, gamitin ito:

sha256sum --ignore-missing -c SHA256SUMS.all

Ipi-print nito ang payload.txt: OK at lalabas na may exit code na 0. Kung wala sa mga pangalang nasa listahan ang naroroon, hindi tahimik na magtatagumpay ang --ignore-missing kapag zero files ang nasuri. Ire-report nito na no file was verified at lalabas na may non-zero exit code. Ito ang behavior na kailangan mo, dahil ang pass na walang nasuring file ay failure na hindi mo mapapansin.

Ilipat ang published digest nang hindi ito binabasa nang manu-mano

Dito talaga bumibigay ang nakasanayang paraan: mano-manong paghahambing ng 64 hexadecimal character. Sinusuri ng mga tao ang unang apat na character at huling apat, pagkatapos ay itinuturing itong tugma. Iyan mismo ang paghahambing na inaasahan ng isang determinadong attacker. Hayaan ang tool ang maghambing. Itakda ang EXPECTED sa digest na kinopya mo mula sa publisher gamit ang EXPECTED= na sinusundan ng pasted value, pagkatapos ay buuin ang iisang linya na 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. Kaya dalawang space din ang nasa format string. Iyan ang format na isinusulat ng sha256sum at binabasa ng -c. Ang file na naglalaman lamang ng digest at wala nang iba 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. May ilang project na nagpa-publish sa BSD tagged style, na gumagamit ng SHA256 (payload.txt) = na 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 behavior ng check, tingnan ang listahan mismo 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 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 sanhi ng problema sa check, bagama't hindi gaanong mapagparaya rito ang mga tool na hindi bahagi ng coreutils. I-normalize ang kopyang itinatago mo gamit ang tr -d '\r' < SHA256SUMS > SHA256SUMS.clean.

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

Isang bagay ang pinatutunayan ng checksum: ang bytes sa iyong disk ay kapareho ng mga bytes na gumawa ng published digest. Ganap nitong natutukoy ang aksidenteng pagkasira ng data. Natutukoy rin nito ang isang attacker na nagpabaya at nagpalit ng file sa download mirror ngunit hindi nakapagbago sa page kung saan inilathala ang digest.

Wala itong pinatutunayan tungkol sa may-akda. Ang digest ay impormasyon tungkol sa bytes, hindi tungkol sa mga tao. Kung iisang page ang naghahatid ng file at digest, maaaring baguhin ng sinumang makapagbago sa isa ang isa pa, at ang iyong OK line ay nangangahulugan lamang na nagkakasundo ang mirror sa sarili nito. Kaya ito ang tuntuning nagpapahalaga sa pagpapatakbo ng checksums: kunin ang digest sa ibang lugar kaysa sa pinanggalingan ng file. Halimbawa, kunin ito sa sariling domain ng project gamit ang TLS (transport layer security), habang ang image ay galing sa mirror o torrent. Sa ganitong paraan, kailangang kontrolin ng attacker ang dalawang lugar sa halip na isa.

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

Kapag mga signature na ang ginagamit

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

Napupunta sa key ang mahinang bahagi. Kapag kinuha mo ang key mula sa parehong page na nagbigay ng file, naibibigay mo sa attacker ang dalawang bahaging kailangan nito. Tapat dito ang GnuPG, at sa unang verification ay ipinapakita nito ang Good signature kasama ng WARNING: This key is not certified with a trusted signature!. Ibig sabihin ng Good signature ay tama ang mathematical verification. Hindi nito ibig sabihin na pagmamay-ari ng project na nasa isip mo ang key. Kunin ang fingerprint mula sa ibang source, gaya ng documentation ng project sa ibang domain o isang 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 sa isang SSH private key, sa parehong dahilan: ang key ang batayan ng trust decision, at minamana ito ng lahat ng kasunod na hakbang.

Isang hakbang pa ang ginagawa ng reproducible builds sa ideyang ito. Itinatali ka pa rin ng published digest sa binary na binuo ng isang machine. Kapag reproducible ang build ng isang project, maaaring i-compile ng sinuman ang parehong source at makakuha ng output na eksaktong magkapareho ang bytes. Dahil dito, makukumpirma ng mga independent builder ang published digest sa halip na hilingin sa iyo na magtiwala sa pahayag ng isang server. Mas mahalaga ito bawat taon habang mas maraming code ang dumarating sa pamamagitan ng automated pipeline at machine-written patch. Ang pagpapasya kung ano ang tatanggapin mo sa isang build ay usapin ng policy, at ang open source policy para sa code na tinulungan ng AI ay tumutugon sa parehong supply chain mula sa kabilang dulo.

Package manager ang gumagawa na nito para sa iyo

Sa Debian at Ubuntu, awtomatikong isinasagawa ng apt ang chain na ito sa bawat install. May SHA-256 digest ang package index para sa bawat .deb file. Nagtataglay ang Release file ng mga digest ng mga index file na iyon, at may signature ang InRelease para sa Release, na chine-check laban sa mga key sa /usr/share/keyrings at /etc/apt/trusted.gpg.d. Kapag naputol ang chain, sinasabi 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 stale file ang ibinigay ng caching proxy o naabutan mo ang mirror habang nagsi-sync.

Ito ang standard na dapat gawing batayan kapag sinasabihan ka 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 mga ito. Maaari ring magbigay ang server ng isang content sa script at ibang content 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. Mga dalawampung segundo lang ang kailangan sa ganitong gawain. Ito rin ang ugaling dapat simulang gawin sa bagong VPS sa unang sampung minuto nito, bago mag-install ng iba pang bagay sa server.

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

Naka-track ang mga package na ini-install ng apt. Hindi kasama rito ang binary na kinopya mo sa /usr/local/bin, at walang nagmo-monitor nito sa system. Ginagawang puwedeng i-check on demand ng listahan ng mga digest ang sitwasyong ito:

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

Walang output ang --quiet kapag tugma ang bawat file. Kapag may hindi tugma, ang mga linyang nag-fail lang ang ipinapakita nito. Kaya ang kawalan ng output ang indikasyon na pumasa ang check, at kinukumpirma ito ng echo $? gamit ang 0. Ito ang format na dapat gamitin sa scheduled job. Mas tahimik ang --status dahil wala itong inilalabas na output at exit status lang ang natitira. Gamitin ang parehong pattern sa aktuwal na mga file sa pamamagitan ng sha256sum /usr/local/bin/* > ~/local-bin.sha256 upang gumawa 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.

Linawin kung ano ang halaga ng baseline na ito. Nakikita nito kung may nabagong file. Hindi nito nakikita ang attacker na mayroon nang root access, dahil kaya ng attacker na baguhin ang inventory.sha256 gaya ng pagbabago niya sa binary. Itago ang listahan sa labas ng machine kung gusto mong magkaroon ito ng tunay na halaga. Bahagi ito ng mas malawak na tanong kung gaano kalaki ang tiwalang aktuwal mong ibinibigay sa isang VPS at kung sino pa ang maaaring maka-access sa disk sa ilalim nito.

FAQ

Nangangahulugan bang ligtas ang download kapag magkatugma ang checksum?

Hindi. Nangangahulugan lamang ito na tugma ang mga byte na mayroon ka sa digest na ikinumpara mo sa mga ito. Kung kontrolado ng attacker ang page na nag-publish ng digest, ipa-publish niya ang digest ng sarili niyang file, at magpi-print ang iyong check ng OK. Pahayag lamang ng consistency ang isang match. Para makapagsabi na ligtas ang file, kailangan ang signature na na-verify laban sa key na nakuha mo mula sa ibang source. Saka lamang mapapasa sa digest ang trust na iyon.

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

Dahil hindi nito nabasa ang file. May hiwalay na line sa itaas nito na nagsasabing No such file or directory, kasama ang pangalan 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 din na nakalista ngunit hindi mo na-download, idagdag ang --ignore-missing. Ang plain na FAILED na walang open or read ay kabaligtarang sitwasyon: nabasa ang file, ngunit hindi tugma ang digest nito.

Sapat na ba ang MD5 para sa pag-verify ng download?

Para sa aksidenteng pagkasira, oo. Hindi basta-basta magkakaroon ng katugmang MD5 digest ang truncated transfer o bad disk block. Laban sa attacker, hindi. Posibleng gumawa ng dalawang magkaibang file na may parehong MD5 digest mula pa noong 2004, at bumigay ang SHA-1 sa isang chosen-prefix collision noong 2020. Gamitin ang SHA-256 line kapag parehong inilalathala ng project ang dalawa. 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 inaalok ng project. Pinagkakatiwalaan ng signature ang digest list, at pagkatapos ay ginagamit ng digest list upang mapagkatiwalaan ang na-download na file.

Paano ko iche-check ang isang file laban sa digest na naka-print sa isang web page?

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