Base di conoscenza Sotto il cofano

Verifica della build

L'open source aiuta solo se il codice che stai eseguendo è il codice che era pubblicato. Nymchat è costruito in modo deterministico in modo che tu possa verificarlo tu stesso, dall'interno del file app o da terminale.

Questa pagina è tradotta automaticamente per comodità. Si applica l'originale inglese.

Build riproducibili

La creazione dell'app genera un file build-manifest.json contenente il commit sorgente, a Hash SHA-256 di ogni asset HTML, JavaScript e CSS servito e un singolo bundleHash su tutto l'insieme di risorse.

L'output dipende solo dal contenuto sorgente: anche il tempo di creazione registrato è lo stesso il timestamp del commit anziché il momento in cui è stata eseguita la build, quindi chiunque ricostruisca lo stesso commit ottiene file identici in byte e lo stesso bundleHash.

Un'azione GitHub ricostruisce quindi ciascun commit in modo indipendente e firma la provenienza della build attestazioni per l'hash e il manifest, quindi esiste un record firmato che lega a bundleHash a un commit nel repository, prodotto da qualcosa di diverso da distribuzione.

Cosa controlla la finestra di dialogo Informazioni

Di nell'intestazione esegue il controllo in tempo reale, nel tuo browser.

La finestra di dialogo Informazioni su Nymchat, che mostra la versione, l'integrità della build e garantisce lo stato canary. — La finestra di dialogo Informazioni su: versione, integrità della build, warrant canary e una linea diretta con lo sviluppatore.

Recupera ogni risorsa effettivamente in esecuzione sulla pagina, ne esegue l'hashing con l'API Web Crypto e confronta con il manifesto. Poi – e questa è la parte che conta – è così ricalcola il bundleHash dagli hash Esso appena calcolato, non da tutto ciò che il manifest afferma e lo cerca nelle attestazioni firmate del repository tramite l'API GitHub.

Questo è ciò che impedisce a una distribuzione di garantire se stessa: servire file modificati insieme a un manifest corrispondente continua a fallire, perché l'hash ricalcolato non ha alcuna attestazione.

Stato	Significa
&controllo; App ufficiale verificata (n/n)	Ogni asset corrisponde, l'hash del bundle ricalcolato è attestato dal repository, E la pagina è servita dal dominio ufficiale.
⚠ Build verificata · non è l'app ufficiale	Il codice è autentico e attestato, ma questo è uno specchio su un altro dominio. Un mirror non può rimuovere questo avviso senza fallire la verifica.
✗ Mancata corrispondenza	Una risorsa non corrisponde a ciò che dice il manifest.
✗ Compilazione non ufficiale	L'hash del bundle ricalcolato non ha alcuna attestazione dal repository: un manifest creato autonomamente.
⚠ Provenienza non raggiungibile	Non è stato possibile raggiungere l'API GitHub, quindi non è stato possibile verificare l'attestazione in alcun modo.

Verificalo tu stesso

Ricostruisci il commit dei nomi della finestra di dialogo Informazioni e confronta:

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

L'hash stampato dovrebbe corrispondere sia a quello nella finestra di dialogo Informazioni che a quello in quel commit riepilogo dell'esecuzione della build-provenienza. Puoi anche controllare la firma direttamente con la CLI GitHub:

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

Le app Android e iOS

Il controllo sopra è un controllo dell'app Web e vale la pena dirlo chiaramente: un'app nativa non può fare la stessa cosa su se stesso. Ciò che viene eseguito sul tuo telefono è il codice macchina compilato, non il file source nel repository e nulla che l'app possa calcolare sul dispositivo è correlato a altro.

Android può fare la cosa migliore. L'installato .apk è un file che l'app può leggere e hash, e l'hash di ogni versione pubblicata è già pubblico: pubblicare nel file Zapstore firma un evento Nostr che trasporta lo SHA-256 dell'APK e lo SHA-256 del suo certificato di firma. Quindi il Androide Di dialog esegue l'hashing dell'APK da cui viene eseguito e recupera quelli firmati eventi, mantiene solo quelli firmati dalla chiave dello sviluppatore e confronta. Mostra i due anche gli hash, così puoi ripetere il check dal dispositivo: scarica l'APK pubblicato, esegui sha256sum su di esso e guarda tu stesso lo stesso evento.

Un'app installata da Google Play non può essere controllata in questo modo, e questo non è un segno che qualcosa sia sbagliato. Google ri-signora ogni upload con la propria chiave e costruisce un APK separato per ogni dispositivo, quindi ciò che atterra sul tuo telefono non è il file prodotto dallo sviluppatore e il suo hash non corrisponde a nulla che potrebbe essere pubblicato. L'app riconosce un'installazione Play e dice così piuttosto che segnalare un fallimento.

iOS non può essere controllato affatto. Apple crittografa e firma nuovamente ogni download individualmente, quindi un hash calcolato sul tuo iPhone è unico per il tuo iPhone e non corrisponde a nulla pubblicato ovunque. La finestra di dialogo Informazioni lo dice apertamente piuttosto che mostrarlo in modo rassicurante stato che non significa nulla. Se vuoi una Nymchat puoi verificarla sull'hardware Apple, usa il web app, che controlla ogni file in esecuzione.

Ciò che nulla di tutto ciò dimostra

Un controllo eseguito da un'app su se stessa non può dimostrare che l'app sia onesta, chiunque l'abbia modificata potrebbe rimuovere anche l'assegno. Ciò che dimostra è il caso ordinario: che ti copiano installata è la copia che è stata pubblicata. Vale la pena averlo perché lo valorizza i confronti sono pubblici, quindi qualcuno diverso da te può controllarli e non essere d'accordo.

Il canarino del mandato

Un warrant canary è una dichiarazione, pubblicata secondo un programma fisso, di cui dispone lo sviluppatore non hanno ricevuto un ordine governativo segreto di cui è vietato divulgare — a Lettera sulla sicurezza nazionale, un ordine FISA. Lo sviluppatore può essere costretto a tacere tale ordine, ma non può essere costretto a mentire, quindi il canarino diventa stantio o scompare stesso il segnale.

Vive dentro canary.json nella radice del repository e viene recuperato direttamente da GitHub, quindi la sua cronologia è verificabile indipendentemente da ciò che dice il sito distribuito. La finestra di dialogo Informazioni lo codifica a colori:

Colore	Significa
Verde – tutto chiaro	Firmato, corrente e la firma corrisponde alla chiave dello sviluppatore. Nessun ordine segreto è stato ricevuto.
Giallo - in ritardo o non tutto chiaro	Non è stato aggiornato entro la data indicata o il suo `allClear` la bandiera è falsa. Non è da escludere un'ordinanza silenziosa.
Rosso - firma non valida o scomparsa	La firma non corrisponde alla chiave dello sviluppatore oppure il file è stato completamente rimosso. Considera questo come un avvertimento serio.

L'ancora della freschezza

Il canary firmato incorpora l'ultima altezza del blocco Bitcoin e l'hash al momento della firma. Quell'hashish non poteva essere conosciuto prima che esistesse il blocco, il che dimostra che il canarino lo era firmato Dopo in un momento specifico anziché prefirmati in massa mesi prima. La finestra di dialogo Informazioni collega l'ancora a un Block Explorer in modo che tu possa controllarlo.