Kennisbank Onder de motorkap

Het verifiëren van de constructie

Open source helpt alleen als de code die u gebruikt, de code is die was gepubliceerd. Nymchat is deterministisch gebouwd, zodat u dat zelf kunt controleren, vanuit de app of vanaf een terminal.

Deze pagina is voor het gemak automatisch vertaald. Het Engelse origineel is de versie die van toepassing is.

Reproduceerbare builds

Het bouwen van de app zendt een build-manifest.json met de broncommit, a SHA-256-hash van elk weergegeven HTML-, JavaScript- en CSS-item, en één bundleHash over die hele activaset.

De uitvoer is alleen afhankelijk van de broninhoud; zelfs de opgenomen bouwtijd is bepalend commit's tijdstempel in plaats van het moment waarop de build werd uitgevoerd - dus iedereen die hetzelfde opnieuw opbouwt commit krijgt byte-identieke bestanden en hetzelfde bundleHash.

Een GitHub-actie herbouwt vervolgens elke commit afzonderlijk en tekent de herkomst van de build attesten voor de hash en het manifest, dus er is een ondertekend record dat een koppelt bundleHash naar een commit in de repository, geproduceerd door iets anders dan de inzet.

Wat het dialoogvenster Over controleert

Over in de header wordt de controle live uitgevoerd in uw browser.

Het Nymchat About-dialoogvenster toont de versie, bouwt integriteit op en garandeert de kanariestatus. — Het Over-dialoogvenster: versie, build-integriteit, warrant canary en een directe lijn naar de ontwikkelaar.

Het haalt elk item dat de pagina daadwerkelijk gebruikt opnieuw op, hasht het met de Web Crypto API en vergelijkt met het manifest. Dan – en dit is het deel dat ertoe doet – het herberekent de bundleHash van de hasj Het gewoon berekend, niet vanaf alles wat het manifest claimt, en zoekt dat op in de ondertekende attesten van de repository via de GitHub-API.

Dat is wat een implementatie ervan weerhoudt om voor zichzelf in te staan: het aanbieden van gewijzigde bestanden samen met een overeenkomend manifest mislukt nog steeds, omdat de opnieuw berekende hash geen attest heeft.

Status	Middelen
&rekening; Geverifieerde officiële app (n/n)	Elke asset komt overeen, de opnieuw berekende bundel-hash wordt bevestigd door de repository, En de pagina wordt aangeboden vanuit het officiële domein.
⚠ Geverifieerde build · niet de officiële app	De code is echt en gecertificeerd, maar dit is een spiegel op een ander domein. Een spiegelserver kan deze waarschuwing niet verwijderen zonder dat de verificatie mislukt.
✗ Mismatch	Een asset komt niet overeen met wat het manifest zegt.
✗ Onofficiële constructie	De opnieuw berekende bundel-hash heeft geen attest van de repository – een zelfgemaakt manifest.
⚠ Herkomst onbereikbaar	De GitHub API kon niet worden bereikt, dus de attestatie kon op geen enkele manier worden gecontroleerd.

Zelf verifiëren

Herbouw de commit met de namen van het dialoogvenster Over en vergelijk:

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>"

De afgedrukte hash moet overeenkomen met die in het Over-dialoogvenster en die in die commit's samenvatting van de build-herkomst. Je kunt de handtekening ook rechtstreeks controleren met de GitHub CLI:

gh attestation verify dist/build-manifest.json --repo Spl0itable/NYM

De Android- en iOS-apps

De bovenstaande controle is een web-app-controle, en de reden is de moeite waard om duidelijk te vermelden: een native app kan zichzelf niet hetzelfde aandoen. Wat op uw telefoon draait, is gecompileerde machinecode, niet de bron in de repository, en niets dat de app op het apparaat kan berekenen, heeft betrekking op de andere.

Android kan het op één na beste doen. De geïnstalleerde .apk is een bestand dat de app kan lezen en hash, en de hash van elke gepubliceerde release is al openbaar: publiceren naar de Zapstore ondertekent een Nostr-evenement met de SHA-256 van de APK en de SHA-256 van het handtekeningcertificaat. Dus de Android Over dialoogvenster hasht de APK waarvan het wordt uitgevoerd en haalt de ondertekende APK's op gebeurtenissen, bewaart alleen de gebeurtenissen die zijn ondertekend door de sleutel van de ontwikkelaar en vergelijkt. Het toont de twee hashes ook, zodat u de controle vanaf het apparaat kunt herhalen: download de gepubliceerde APK, voer deze uit sha256sum erop en kijk zelf naar dezelfde gebeurtenis.

Een app die via Google Play is geïnstalleerd, kan op deze manier niet worden gecontroleerd, en dat is geen teken dat er iets mis is. Google her-ondertekent elke upload met zijn eigen sleutel en bouwt een aparte APK voor elk apparaat, dus wat op je telefoon landt, is niet het bestand dat de ontwikkelaar heeft geproduceerd en de hash matcht niets dat zou kunnen worden gepubliceerd. De app herkent een Play-installatie en zegt dat in plaats van een storing te melden.

iOS kan helemaal niet worden gecontroleerd. Apple codeert en ondertekent elke download opnieuw individueel, dus een hash die op uw iPhone wordt berekend, is uniek voor uw iPhone en komt met niets overeen waar dan ook gepubliceerd. Het Over-dialoogvenster zegt dit ronduit in plaats van een geruststellende toon te tonen status die niets betekent. Als je een Nymchat wilt die je kunt verifiëren op Apple-hardware, gebruik dan internet app, die elk bestand controleert dat wordt uitgevoerd.

Wat dit allemaal niet bewijst

Een controle die een app op zichzelf uitvoert, kan niet bewijzen dat de app eerlijk is – wie deze ook heeft aangepast kan de cheque ook verwijderen. Wat het bewijst is het gewone geval: dat de kopie jou geïnstalleerd is de kopie die is gepubliceerd. Dat is de moeite waard omdat de mensen er waarde aan hechten Vergelijkingen zijn openbaar, dus iemand anders dan jij kunt ze controleren en het er niet mee eens zijn.

De warrantkanarie

Een warrant canary is een verklaring, gepubliceerd volgens een vast schema, die de ontwikkelaar heeft niet een geheim overheidsbevel hebben ontvangen dat zij niet openbaar mogen maken – a National Security Letter, een FISA-bevel. De ontwikkelaar kan gedwongen worden erover te zwijgen zo'n bevel, maar kan niet worden gedwongen om te liegen, dus de kanarie wordt oud of verdwijnt zelf het signaal.

Het leeft erin canary.json in de root van de repository en wordt direct opgehaald van GitHub, zodat de geschiedenis ervan controleerbaar is, onafhankelijk van wat de geïmplementeerde site zegt. Het Over-dialoogvenster geeft het een kleurcode:

Kleur	Middelen
Groente – allemaal duidelijk	Ondertekend, actueel en de handtekening komt overeen met de sleutel van de ontwikkelaar. Er is geen geheim bevel ontvangen.
Geel – te laat, of niet allemaal duidelijk	Het is niet vernieuwd op de aangegeven datum of op de aangegeven datum `allClear` vlag is vals. Een stilzwijgend bevel kan niet worden uitgesloten.
Rood — ongeldige handtekening, of verdwenen	De handtekening komt niet overeen met de sleutel van de ontwikkelaar, of het bestand is volledig verwijderd. Beschouw dit als een serieuze waarschuwing.

Het versheidsanker

De ondertekende kanarie bevat de nieuwste Bitcoin-blokhoogte en hash op het moment van ondertekening. Die hasj kon niet bekend zijn voordat het blok bestond, wat bewijst dat de kanarie dat wel was ondertekend na een specifiek tijdstip in plaats van maanden eerder vooraf in bulk te ondertekenen. Het dialoogvenster Info koppelt het anker aan een blokverkenner, zodat u het kunt controleren.