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.
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/NYMLe 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.