Wissensdatenbank Unter der Haube

Überprüfung des Builds

Open Source hilft nur, wenn der Code, den Sie ausführen, der Code ist, der es war veröffentlicht. Nymchat ist deterministisch aufgebaut, sodass Sie dies selbst von innen überprüfen können App oder von einem Terminal aus.

Diese Seite wurde der Einfachheit halber maschinell übersetzt. Es gilt das englische Original.

Reproduzierbare Builds

Beim Erstellen der App wird a ausgegeben build-manifest.json enthält den Quell-Commit, a SHA-256-Hash jedes bereitgestellten HTML-, JavaScript- und CSS-Assets und eines einzelnen bundleHash über das gesamte Asset-Set.

Die Ausgabe hängt nur vom Quellinhalt ab – sogar die aufgezeichnete Erstellungszeit ist davon abhängig Der Zeitstempel des Commits und nicht der Moment, in dem der Build ausgeführt wurde – sodass jeder, der es neu erstellt, dasselbe tut Commit erhält byteidentische Dateien und dasselbe bundleHash.

Eine GitHub-Aktion erstellt dann jedes Commit unabhängig neu und signiert die Build-Herkunft Bescheinigungen für den Hash und das Manifest, daher gibt es einen signierten Datensatz, der a verknüpft bundleHash zu einem Commit im Repository, der von etwas anderem als dem erstellt wurde Bereitstellung.

Was im Info-Dialog überprüft wird

Um Im Header wird die Prüfung live in Ihrem Browser ausgeführt.

Das Nymchat-Info-Dialogfeld zeigt die Version, die Build-Integrität und den Warrant-Canary-Status an. — Der Info-Dialog: Version, Build-Integrität, Warrant Canary und ein direkter Draht zum Entwickler.

Es ruft jedes Asset, das auf der Seite tatsächlich ausgeführt wird, erneut ab, hasht es mit der Web Crypto API und vergleicht mit dem Manifest. Dann – und das ist der entscheidende Teil – es berechnet das neu bundleHash aus den Hashes Es nur berechnet, nicht aus alles, was das Manifest behauptet, und sucht danach in den signierten Bescheinigungen des Repositorys über die GitHub-API.

Das ist es, was eine Bereitstellung davon abhält, für sich selbst zu bürgen: geänderte Dateien zusammen mit bereitzustellen Ein passendes Manifest schlägt immer noch fehl, da der neu berechnete Hash keine Bescheinigung hat.

Status	Bedeutet
&überprüfen; Verifizierte offizielle App (n/n)	Jedes Asset stimmt überein, der neu berechnete Bundle-Hash wird vom Repository bestätigt. Und Die Seite wird von der offiziellen Domain bereitgestellt.
⚠ Verifizierter Build · nicht die offizielle App	Der Code ist echt und beglaubigt, es handelt sich jedoch um einen Spiegel auf einer anderen Domain. Ein Spiegel kann diese Warnung nicht entfernen, ohne dass die Überprüfung fehlschlägt.
✗ Nichtübereinstimmung	Ein Asset führt keinen Hash zu dem aus, was im Manifest steht.
✗ Inoffizieller Build	Der neu berechnete Bundle-Hash hat keine Bestätigung aus dem Repository – ein selbst erstelltes Manifest.
⚠ Provenienz nicht auffindbar	Die GitHub-API konnte nicht erreicht werden, daher konnte die Attestierung auch nicht überprüft werden.

Überprüfen Sie es selbst

Erstellen Sie die Namen des Commit-Dialogfelds neu und vergleichen Sie:

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

Der gedruckte Hash sollte sowohl mit dem im Info-Dialog als auch mit dem in diesem Commit übereinstimmen Zusammenfassung des Build-Provenienz-Laufs. Sie können die Signatur auch direkt mit der GitHub-CLI überprüfen:

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

Die Android- und iOS-Apps

Bei der obigen Prüfung handelt es sich um eine Web-App-Prüfung, und der Grund dafür sollte klar angegeben werden: eine native App kann sich selbst nicht das Gleiche antun. Was auf Ihrem Telefon läuft, ist kompilierter Maschinencode, nicht der Quelle im Repository, und nichts, was die App auf dem Gerät berechnen kann, bezieht sich auf die Quelle andere.

Android kann das Nächstbeste tun. Die installiert .apk ist eine Datei, die die App lesen kann und Hash, und der Hash jeder veröffentlichten Veröffentlichung ist bereits öffentlich: Veröffentlichung im Zapstore signiert ein Nostr-Ereignis mit dem SHA-256 des APK und dem SHA-256 seines Signaturzertifikats. Also die Android Um Der Dialog hasht die APK, von der aus er ausgeführt wird, und ruft die signierten Dateien ab Ereignisse, behält nur diejenigen, die mit dem Schlüssel des Entwicklers signiert sind, und vergleicht sie. Es zeigt die beiden Hashes ebenfalls, sodass Sie die Überprüfung auf dem Gerät wiederholen können: Laden Sie die veröffentlichte APK herunter und führen Sie sie aus sha256sum darauf und schauen Sie sich das gleiche Ereignis selbst an.

Eine über Google Play installierte App kann auf diese Weise nicht überprüft werden, und das ist kein Zeichen, dass alles falsch ist. Google unterschreibt jedes Upload mit seinem eigenen Schlüssel und baut für jedes Gerät ein separates APK, so dass das, was auf Ihrem Telefon landet, nicht die Datei ist, die der Entwickler produziert hat, und sein Hash matcht nichts, das veröffentlicht werden könnte. Die App erkennt eine Play-Installation und sagt so anstatt einen Fehler zu melden.

iOS kann überhaupt nicht überprüft werden. Apple verschlüsselt und signiert jeden Download neu einzeln, sodass ein auf Ihrem iPhone berechneter Hash einzigartig für Ihr iPhone ist und mit nichts übereinstimmt irgendwo veröffentlicht. Das Info-Dialogfeld sagt dies direkt und nicht beruhigend Status, der nichts bedeutet. Wenn Sie einen Nymchat wünschen, den Sie auf Apple-Hardware überprüfen können, nutzen Sie das Internet app, die jede Datei überprüft, die sie ausführt.

Was das alles nicht beweist

Eine Prüfung, die eine App selbst durchführt, kann nicht beweisen, dass die App ehrlich ist – wer auch immer sie geändert hat könnte den Scheck auch entfernen. Was es beweist, ist der gewöhnliche Fall: dass die Kopie Sie ist Installiert ist die Kopie, die veröffentlicht wurde. Das ist es wert, weil man es schätzt Vergleiche sind öffentlich, sodass jemand anderes als Sie sie überprüfen und widersprechen kann.

Der Haftkanarienvogel

Ein Warrant Canary ist eine nach einem festen Zeitplan veröffentlichte Erklärung des Entwicklers nicht eine geheime staatliche Anordnung erhalten haben, deren Offenlegung ihnen verboten ist – a National Security Letter, eine FISA-Anordnung. Der Entwickler kann gezwungen werden, darüber Stillschweigen zu bewahren Ein solcher Befehl kann jedoch nicht zur Lüge gezwungen werden, so dass der Kanarienvogel abgestanden ist oder verschwindet selbst das Signal.

Es lebt darin canary.json im Stammverzeichnis des Repositorys und wird direkt abgerufen von GitHub, sodass sein Verlauf unabhängig von den Aussagen der bereitgestellten Site überprüfbar ist. Das Dialogfeld „Info“ weist eine Farbcodierung auf:

Farbe	Bedeutet
Grün – alles klar	Signiert, aktuell und die Signatur stimmt mit dem Schlüssel des Entwicklers überein. Es ist kein geheimer Befehl eingegangen.
Gelb – überfällig oder nicht alles klar	Es wurde nicht bis zum angegebenen Datum aktualisiert `allClear` Flagge ist falsch. Eine stillschweigende Anordnung kann nicht ausgeschlossen werden.
Rot – Ungültige Signatur oder verschwunden	Die Signatur stimmt nicht mit dem Schlüssel des Entwicklers überein oder die Datei wurde vollständig entfernt. Betrachten Sie dies als ernste Warnung.

Der Frischeanker

Der signierte Kanarienvogel bettet die neueste Bitcoin-Blockhöhe und den neuesten Hash zum Zeitpunkt der Signatur ein. Dieser Hash konnte nicht bekannt sein, bevor der Block existierte, was beweist, dass der Kanarienvogel existierte unterzeichnet nach zu einem bestimmten Zeitpunkt und nicht mehrere Monate zuvor in großen Mengen vorab unterzeichnet. Das Dialogfeld „Info“ verknüpft den Anker mit einem Block-Explorer, damit Sie ihn überprüfen können.