Base de connaissances Sous le capot

Vérification de la construction

L'open source n'est utile que si le code que vous exécutez est le code qui a été publié. Nymchat est construit de manière déterministe afin que vous puissiez le vérifier vous-même, depuis l'intérieur du application ou depuis un terminal.

Cette page est traduite automatiquement pour plus de commodité. La version originale anglaise est la version qui s’applique.

Constructions reproductibles

La construction de l'application émet un build-manifest.json contenant le commit source, un Hachage SHA-256 de chaque ressource HTML, JavaScript et CSS servie, et un seul bundleHash sur l’ensemble de cet ensemble d’actifs.

La sortie dépend uniquement du contenu source — même le temps de construction enregistré est le l'horodatage du commit plutôt que le moment où la construction a été exécutée - donc quiconque reconstruit le même commit obtient des fichiers identiques en octets et pareil bundleHash.

Une action GitHub reconstruit ensuite chaque commit indépendamment et signe la provenance du build attestations pour le hachage et le manifeste, il y a donc un enregistrement signé liant un bundleHash à un commit dans le dépôt, produit par autre chose que le déploiement.

Ce que vérifie la boîte de dialogue À propos

À propos dans l'en-tête, la vérification est effectuée en direct, dans votre navigateur.

La boîte de dialogue À propos de Nymchat, affichant la version, l'intégrité de la construction et le statut Canary. — La boîte de dialogue À propos : version, intégrité de la construction, garantie Canary et une ligne directe avec le développeur.

Il récupère chaque élément que la page exécute réellement, le hache avec l'API Web Crypto et se compare au manifeste. Ensuite - et c'est la partie qui compte - il recalcule le bundleHash à partir des hachages il juste calculé, pas à partir de tout ce que le manifeste revendique, et recherche cela dans les attestations signées du référentiel via l'API GitHub.

C'est ce qui empêche un déploiement de se porter garant : servir les fichiers modifiés avec un manifeste correspondant échoue toujours, car le hachage recalculé n'a aucune attestation.

Statut	Moyens
&vérifier; Application officielle vérifiée (n/n)	Chaque actif correspond, le hachage du bundle recalculé est attesté par le référentiel, et la page est servie à partir du domaine officiel.
⚠ Version vérifiée · pas l'application officielle	Le code est authentique et attesté, mais il s'agit d'un miroir sur un autre domaine. Un miroir ne peut pas supprimer cet avertissement sans échouer la vérification.
✗ Inadéquation	Un actif ne correspond pas à ce que dit le manifeste.
✗ Version non officielle	Le hachage du bundle recalculé n’a aucune attestation du référentiel – un manifeste créé par vous-même.
⚠ Provenance inaccessible	L'API GitHub n'a pas pu être atteinte, l'attestation n'a donc pas pu être vérifiée d'une manière ou d'une autre.

Le vérifier vous-même

Reconstruisez le commit des noms de boîte de dialogue À propos et comparez :

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

Le hachage imprimé doit correspondre à la fois à celui de la boîte de dialogue À propos et à celui de ce commit. résumé de l’exécution de build-provenance. Vous pouvez également vérifier la signature directement avec la CLI GitHub :

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

Les applications Android et iOS

La vérification ci-dessus est une vérification d'application Web, et la raison mérite d'être clairement indiquée : une application native ne peut pas se faire la même chose. Ce qui s'exécute sur votre téléphone est du code machine compilé, et non le source dans le référentiel, et rien de ce que l'application peut calculer sur l'appareil ne le relie au autre.

Android peut faire la meilleure chose à faire. L'installé .apk est un fichier que l'application peut lire et le hachage, et le hachage de chaque version publiée est déjà public : publication sur le Zapstore signe un événement Nostr portant le SHA-256 de l'APK et le SHA-256 de son certificat de signature. Donc le Android À propos la boîte de dialogue hache l'APK à partir duquel il s'exécute, récupère ceux signés événements, conserve uniquement ceux signés par la clé du développeur et compare. Il montre les deux également des hachages, afin que vous puissiez répéter la vérification de l'appareil : téléchargez l'APK publié, exécutez sha256sum dessus, et regardez vous-même le même événement.

Une application installée depuis Google Play ne peut pas être vérifiée de cette façon, et ce n'est pas un signe que quelque chose ne va pas. Google ré-signe chaque téléchargement avec sa propre clé et construit un APK distinct pour chaque appareil, de sorte que ce qui atterrit sur votre téléphone n'est pas le fichier produit par le développeur et son hash ne correspond à rien qui pourrait être publié. L'application reconnaît une installation Play et le dit plutôt que de signaler un échec.

iOS ne peut pas du tout être vérifié. Apple crypte et re-signe chaque téléchargement individuellement, donc un hachage calculé sur votre iPhone est unique à votre iPhone et ne correspond à rien publié n'importe où. La boîte de dialogue À propos de le dit clairement plutôt que de montrer un message rassurant. un statut qui ne veut rien dire. Si vous souhaitez un Nymchat que vous pouvez vérifier sur du matériel Apple, utilisez le Web app, qui vérifie chaque fichier qu'elle exécute.

Ce que rien de tout cela ne prouve

Une vérification sur laquelle une application s'exécute elle-même ne peut pas prouver qu'elle est honnête, quel que soit celui qui l'a modifiée. pourrait également supprimer le chèque. Ce que cela prouve est le cas ordinaire : que la copie que vous installé est la copie qui a été publiée. Cela vaut la peine parce que les valeurs que cela les comparaisons sont publiques, donc quelqu'un d'autre que vous peut les vérifier et être en désaccord.

Le canari à mandat

Un warrant canary est une déclaration, publiée selon un calendrier fixe, selon laquelle le promoteur a pas reçu un ordre gouvernemental secret qu’il leur est interdit de divulguer – un Lettre de sécurité nationale, une ordonnance de la FISA. Le développeur peut être contraint de garder le silence sur un tel ordre, mais on ne peut pas l'obliger à mentir, donc le canari devient obsolète ou disparaît. lui-même le signal.

Il vit dans canary.json à la racine du référentiel et est récupéré directement depuis GitHub, son historique est donc vérifiable indépendamment de tout ce que dit le site déployé. La boîte de dialogue À propos de ce code couleur :

Couleur	Moyens
Vert — tout est clair	Signé, actuel et la signature correspond à la clé du développeur. Aucun ordre secret n'a été reçu.
Jaune — en retard, ou tout n'est pas clair	Il n'a pas été actualisé à sa date indiquée, ni à sa `allClear` le drapeau est faux. Un ordre silencieux ne peut être exclu.
Rouge — signature invalide ou disparue	La signature ne correspond pas à la clé du développeur ou le fichier a été entièrement supprimé. Considérez cela comme un avertissement sérieux.

L'ancre de la fraîcheur

Le canari signé intègre la dernière hauteur de bloc Bitcoin et le hachage au moment de la signature. Ce hachage n'aurait pas pu être connu avant l'existence du bloc, ce qui prouve que le canari était signé après à un moment précis plutôt que pré-signé en masse des mois plus tôt. La boîte de dialogue À propos de lie l'ancre à un explorateur de blocs afin que vous puissiez la vérifier.