Kennisbasis Onder die enjinkap
Verifieer tans die bou
Oopbron help net as die kode wat jy gebruik die kode is wat was gepubliseer. Nymchat is deterministies gebou sodat jy dit self kan kontroleer, van binne die app of vanaf 'n terminaal.
Hierdie bladsy is gerieflikheidshalwe masjienvertaal. Die Engelse oorspronklike is die weergawe wat van toepassing is.
Reproduceerbare bouwerk
Die bou van die toepassing gee 'n uit build-manifest.json wat die bronverpligting bevat, a
SHA-256-hash van elke bediende HTML-, JavaScript- en CSS-bate, en 'n enkele
bundleHash oor daardie hele batestel.
Die uitset hang slegs af van die broninhoud - selfs die aangetekende boutyd is die
commit se tydstempel eerder as die oomblik wat die bou geloop het - dus enigiemand wat dieselfde herbou
commit kry byte-identiese lêers en dieselfde bundleHash.
'n GitHub-aksie herbou dan elke verbintenis onafhanklik en teken bouherkoms
attests vir die hash en die manifes, so daar is 'n getekende rekord wat a
bundleHash na 'n commit in die bewaarplek, geproduseer deur iets anders as die
ontplooiing.
Wat die Oor-dialoog kontroleer
Oor in die kop loop die tjek regstreeks, in jou blaaier.
Dit herhaal elke bate wat die bladsy eintlik loop, hashes dit met die Web Crypto API, en
vergelyk met die manifes. Dan - en dit is die deel wat saak maak - dit
herbereken die bundleHash uit die hashes dit net bereken, nie van nie
enigiets wat die manifes beweer, en soek dit op in die bewaarplek se ondertekende attesten
deur die GitHub API.
Dit is wat keer dat 'n ontplooiing vir homself instaan: die diens van gewysigde lêers saam met 'n bypassende manifes misluk steeds, omdat die herberekende hash geen attest het nie.
| Status | Beteken |
|---|---|
| ✓ Geverifieerde amptelike program (n/n) | Elke bate stem ooreen, die herberekende bondel-hash word deur die bewaarplek bevestig, en die bladsy word bedien vanaf die amptelike domein. |
| ⚠ Geverifieerde bou · nie die amptelike toepassing nie | Die kode is eg en bekragtig, maar dit is 'n spieël op 'n ander domein. 'n Spieël kan nie hierdie waarskuwing verwyder sonder om verifikasie te misluk nie. |
| ✗ Mismatch | 'n Bate stem nie ooreen met wat die manifes sê nie. |
| ✗ Nie-amptelike bou | Die herberekende bundel-hash het geen attest van die bewaarplek nie - 'n selfgemaakte manifes. |
| ⚠ Herkoms onbereikbaar | Die GitHub API kon nie bereik word nie, dus kon die attestasie nie nagegaan word nie. |
Verifieer dit self
Herbou die commit die Oor-dialoogname en vergelyk:
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>"Die gedrukte hash moet ooreenstem met beide die een in die Oor dialoog en die een in daardie commit s'n bou-herkomslopie opsomming. U kan ook die handtekening direk met die GitHub CLI nagaan:
gh attestation verify dist/build-manifest.json --repo Spl0itable/NYMDie Android- en iOS-toepassings
Die tjek hierbo is 'n webtoepassingkontrole, en die rede is die moeite werd om dit duidelik te noem: 'n inheemse toepassing kan nie dieselfde ding aan homself doen nie. Wat op jou foon loop, is saamgestelde masjienkode, nie die bron in die bewaarplek, en niks wat die toepassing op die toestel kan bereken, hou verband met die ander.
Android kan die volgende beste ding doen. Die geïnstalleerde .apk is 'n lêer wat die toepassing kan lees
en hash, en die hash van elke gepubliseerde vrystelling is reeds publiek: publisering aan die
Zapstore
teken 'n Nostr-gebeurtenis wat die APK se SHA-256 en sy ondertekeningsertifikaat se SHA-256 dra. Dus die
Android Oor dialoog hashes die APK waaruit dit loop, haal diegene wat onderteken is
gebeure, hou slegs dié wat deur die ontwikkelaar se sleutel onderteken is, en vergelyk. Dit wys die twee
hashes ook, sodat jy die merk van die toestel kan herhaal: laai die gepubliseerde APK af, hardloop
sha256sum daarop, en kyk self na dieselfde gebeurtenis.
'n Toepassing wat vanaf Google Play geïnstalleer is, kan nie op hierdie manier nagegaan word nie, en dit is nie 'n teken dat iets verkeerd is nie. Google heronderteken elke oplaai met sy eie sleutel en bou 'n aparte APK vir elke toestel, sodat wat op jou selfoon land nie die bestand wat die ontwikkelaar geproduseer het nie en sy hash pas niks wat gepubliseer kan word nie. Die app herken 'n Play install en sê dit eerder as om 'n mislukking te rapporteer.
iOS kan glad nie nagegaan word nie. Apple enkripteer en herteken elke aflaai individueel, so 'n hash wat op jou iPhone bereken word, is uniek aan jou iPhone en pas by niks nie enige plek gepubliseer. Die Oor-dialoog sê dit reguit eerder as om 'n gerusstellende te toon status wat niks beteken nie. As jy 'n Nymchat wil hê, kan jy op Apple hardeware verifieer, gebruik die web app, wat wel elke lêer wat dit loop, nagaan.
'n Kontrole wat 'n toepassing op homself uitvoer, kan nie bewys dat die toepassing eerlik is nie - wie dit ook al gewysig het kan die tjek ook verwyder. Wat dit bewys is die gewone geval: dat die kopie jy geïnstalleer is die kopie wat gepubliseer is. Dit is die moeite werd om te hê, want hulle waardeer dit vergelykings is publiek, so iemand anders as jy kan dit nagaan en nie saamstem nie.
Die lasbrief kanarie
'n Lasbriefkanarie is 'n verklaring, gepubliseer op 'n vaste skedule, wat die ontwikkelaar het nie 'n geheime regeringsbevel ontvang wat hulle verbied word om bekend te maak — a Nasionale Veiligheidsbrief, 'n FISA-bevel. Die ontwikkelaar kan gedwing word om stil te bly oor so 'n bevel, maar kan nie gedwing word om te lieg nie, so die kanarie wat verjaar of verdwyn is self die sein.
Dit woon in canary.json aan die wortel van die bewaarplek en word direk gehaal
van GitHub, dus is die geskiedenis daarvan ouditeerbaar, onafhanklik van wat ook al die ontplooide webwerf sê.
Die Oor-dialoog kleurkodeer dit:
| Kleur | Beteken |
|---|---|
| Groen - alles duidelik | Geteken, huidige en die handtekening pas by die ontwikkelaar se sleutel. Geen geheime bevel is ontvang nie. |
| Geel — agterstallig, of nie alles duidelik nie | Dit is nie verfris teen sy vermelde datum, of sy allClear vlag is vals. ’n Gestilde bevel kan nie uitgesluit word nie. |
| Rooi — ongeldige handtekening, of weg | Die handtekening pas nie by die ontwikkelaar se sleutel nie, of die lêer is heeltemal verwyder. Behandel dit as 'n ernstige waarskuwing. |
Die varsheid anker
Die getekende kanarie sluit die nuutste Bitcoin-blokhoogte en hash in op die oomblik van ondertekening. Daardie hasj kon nie bekend gewees het voordat die blok bestaan het nie, wat bewys die kanarie was onderteken na 'n spesifieke tydstip eerder as wat maande vroeër in grootmaat vooraf onderteken is. Die Oor-dialoog koppel die anker aan 'n blokverkenner sodat jy dit kan nagaan.