Batayan ng kaalaman Sa ilalim ng talukbong
Bine-verify ang build
Nakakatulong lang ang open source kung ang code na iyong pinapatakbo ay ang code noon inilathala. Ang Nymchat ay binuo nang deterministiko upang masuri mo iyon sa iyong sarili, mula sa loob ng app o mula sa isang terminal.
Ang pahinang ito ay isinalin sa makina para sa kaginhawahan. Ang orihinal na Ingles ay ang bersyon na naaangkop.
Reproducible build
Ang pagbuo ng app ay naglalabas ng a build-manifest.json naglalaman ng source commit, a
SHA-256 hash ng bawat naihatid na HTML, JavaScript at CSS asset, at isang solong
bundleHash sa buong set ng asset na iyon.
Ang output ay nakasalalay lamang sa pinagmulang nilalaman — kahit na ang naitala na oras ng pagbuo ay ang
timestamp ng commit kaysa sa sandaling tumakbo ang build — kaya ganoon din ang muling pagtatayo ng sinuman
commit ay nakakakuha ng mga byte-magkaparehong file at pareho bundleHash.
Ang isang GitHub Action ay muling bubuo sa bawat commit nang nakapag-iisa at pumipirma ng build-provenance
mga pagpapatotoo para sa hash at manifest, kaya mayroong nilagdaang talaan na nagtali a
bundleHash sa isang commit sa repository, na ginawa ng isang bagay maliban sa
deployment.
Ano ang sinusuri ng dialog na Tungkol
Tungkol sa sa header pinapatakbo ang tseke nang live, sa iyong browser.
Kinukuha nito muli ang bawat asset na aktwal na pinapatakbo ng page, hina-hash ito gamit ang Web Crypto API, at
inihahambing laban sa manifest. Pagkatapos - at ito ang bahagi na mahalaga - ito
nirecompute ang bundleHash mula sa mga hash ito kalkulado lang, hindi galing
anuman ang sinasabi ng manifest, at tinitingnan iyon sa mga nilagdaang pagpapatotoo ng repositoryo
sa pamamagitan ng GitHub API.
Iyan ang pumipigil sa isang deployment mula sa pagtiyak para sa sarili nito: paghahatid ng mga binagong file kasama ng nabigo pa rin ang isang katugmang manifest, dahil walang pagpapatunay ang na-recompute na hash.
| Katayuan | ibig sabihin |
|---|---|
| ✓ Na-verify na opisyal na app (n/n) | Ang bawat asset ay tumutugma, ang recomputed bundle hash ay pinatutunayan ng repository, at inihahatid ang page mula sa opisyal na domain. |
| ⚠ Na-verify na build · hindi ang opisyal na app | Ang code ay tunay at pinatunayan, ngunit ito ay isang salamin sa ibang domain. Hindi maalis ng salamin ang babalang ito nang hindi nabigo ang pag-verify. |
| ✗ Hindi tugma | Hindi hina-hash ng asset ang sinasabi ng manifest. |
| ✗ Hindi opisyal na build | Ang recomputed bundle hash ay walang pagpapatunay mula sa repository - isang self-made na manifest. |
| ⚠ Ang pinagmulan ay hindi maabot | Ang GitHub API ay hindi maabot, kaya ang pagpapatunay ay hindi masuri sa alinmang paraan. |
Bine-verify ito sa iyong sarili
Buuin muli ang commit ang Tungkol sa mga pangalan ng dialog at ihambing:
git clone https://github.com/Spl0itable/NYM
cd NYM
git checkout <commit shown in the About dialog>
npm ci
npm run build # prints "Build hash: <bundleHash>"
Ang naka-print na hash ay dapat tumugma sa parehong nasa dialog ng Tungkol at sa isa sa commit na iyon buod ng build-provenance run. Maaari mo ring suriin ang pirma nang direkta sa GitHub CLI:
gh attestation verify dist/build-manifest.json --repo Spl0itable/NYM
Ang mga Android at iOS app
Ang tseke sa itaas ay isang web-app check, at ang dahilan ay nararapat na sabihin nang malinaw: isang katutubong app hindi maaaring gawin ang parehong bagay sa sarili. Ang tumatakbo sa iyong telepono ay pinagsama-samang machine code, hindi ang pinagmulan sa repositoryo, at walang maiuugnay ang app sa device sa isa sa iba pa.
Magagawa ng Android ang susunod na pinakamahusay na bagay. Ang naka-install .apk ay isang file na mababasa ng app
at hash, at ang hash ng bawat nai-publish na release ay pampubliko na: pag-publish sa
Zapstore
nilagdaan ang isang kaganapan sa Nostr na may dalang SHA-256 ng APK at SHA-256 ng certificate sa pagpirma nito. Kaya ang
Android Tungkol sa hina-hash ng dialog ang APK kung saan ito tumatakbo, kinukuha ang mga nilagdaan
mga kaganapan, pinapanatili lamang ang mga nilagdaan ng susi ng developer, at naghahambing. Ipinapakita nito ang dalawa
pati na rin ang mga hash, para maulit mo ang pag-check off sa device: i-download ang na-publish na APK, patakbuhin
sha256sum dito, at tingnan mo mismo ang parehong kaganapan.
Ang isang app na naka-install mula sa Google Play ay hindi maaaring suriin sa ganitong paraan, at ito ay hindi isang tanda na ang anumang bagay ay mabuti. Google re-signs ang bawat pag-upload na may kanyang sarili na key at binuo ng isang separatong APK para sa bawat device, kaya kung ano ang landed sa iyong telepono ay hindi ang file na itinatag ng developer at ang kanyang hash matches walang bagay na maaaring i-publish. Ang app ay tinatanggap ng isang Play installer at sinabi na ito sa halip kaysa sa pag-report ng isang pag-aralan. upang i-check ang isang build sa iyo, i-install ang APK na inilathala nang direkta.
Hindi masusuri ang iOS. Ini-encrypt at muling pinipirmahan ng Apple ang bawat pag-download nang paisa-isa, kaya ang isang hash na na-compute sa iyong iPhone ay natatangi sa iyong iPhone at walang tugma na-publish kahit saan. Ang dialog na Tungkol dito ay tahasang sinasabi ito sa halip na magpakita ng isang katiyakan status na walang ibig sabihin. Kung gusto mo ng Nymchat na maaari mong i-verify sa Apple hardware, gamitin ang web app, na sinusuri ang bawat file na pinapatakbo nito.
Ang pagsuri sa isang app na tumatakbo sa sarili nito ay hindi makapagpapatunay na ang app ay tapat — sinuman ang nagbago nito maaari ring tanggalin ang tseke. Ang pinatutunayan nito ay ang ordinaryong kaso: na ang kopya mo Ang naka-install ay ang kopya na nai-publish. Iyon ay nagkakahalaga ng pagkakaroon dahil pinahahalagahan ito pampubliko ang mga paghahambing, kaya maaaring suriin ng iba maliban sa iyo, at hindi sumasang-ayon.
Ang warrant canary
Ang warrant canary ay isang pahayag, na inilathala sa isang nakapirming iskedyul, na mayroon ang developer hindi nakatanggap ng lihim na utos ng pamahalaan na ipinagbabawal nilang ibunyag - a National Security Letter, isang utos ng FISA. Maaaring mapilitan ang developer na manatiling tahimik ganoong utos, ngunit hindi mapipilitang magsinungaling, kaya ang kanaryo ay nauubos o nawawala mismo ang signal.
Nakatira ito sa canary.json sa ugat ng repositoryo at direktang kinukuha
mula sa GitHub, kaya ang kasaysayan nito ay maaring ma-audit nang independyente sa anumang sinasabi ng naka-deploy na site.
Ang About dialog color-codes ito:
| Kulay | ibig sabihin |
|---|---|
| Berde — malinaw ang lahat | Ang lagda, kasalukuyan, at ang lagda ay tumutugma sa susi ng developer. Walang lihim na utos ang natanggap. |
| Dilaw — overdue, o hindi lahat malinaw | Hindi ito na-refresh ng nakasaad na petsa nito, o nito allClear huwad ang bandila. Ang isang pinatahimik na utos ay hindi maaaring ilabas. |
| Pula — di-wastong lagda, o nawala | Ang lagda ay hindi tumutugma sa susi ng developer, o ang file ay ganap na naalis. Tratuhin ito bilang isang seryosong babala. |
Ang kasariwaan anchor
Ang nilagdaang canary ay naka-embed ng pinakabagong Bitcoin block height at hash sa sandali ng pagpirma. Ang hash na iyon ay hindi maaaring malaman bago ang bloke ay umiiral, na nagpapatunay na ang kanaryo ay pinirmahan pagkatapos isang partikular na punto sa oras sa halip na paunang nilagdaan nang maramihang buwan na mas maaga. Ang dialog na Tungkol sa ay nagli-link sa anchor sa isang block explorer para masuri mo ito.