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

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.