Technical committee: Check runtime upgrade hash compliance

Nodes Duniter-v2s
,
1

Comment vérifier que ce hash blake correspond bien au runtime de la preimage de la proposal ?

Je trouve que la doc actuellement fournit dans le repo pas très satisfaisante. Je n’ai jamais compris comment comparer les hash d’uun runtime d’une proposual avec le hash d’un runtime compilé, malgré toutes les tentatives que j’ai pu trouver dans la doc du repo et les postes du forum lors des différents runtime upgrade.
Ou alors je n’ai pas compris quelque chose, auquel cas dites le moi.
Ce tuto est une proposition de procédure ne nécessitant pas une confiance aveugle à la release du gitlab.
Vous pouvez la challenger et si elle vous conviens, je propose d’en faire une doc en anglais dans le repo duniter (et le wiki).

La solution la plus simple que j’ai trouvée, que vous soyez sur Linux ou mac :

1 . Ouvrez un fichier texte et mettez-y ce mini script :

WASM_BYTES=0x42...

echo $WASM_BYTES | xxd -r -p | python3 -c "import sys, hashlib; print('0x' + hashlib.blake2b(sys.stdin.buffer.read(), digest_size=32).hexdigest())"

2 . Remplacez simplement la valeur de WASM_BYTES par le code: Bytes du runtime wasm que vous trouverez directement sur la preimage.

2a.

image
image162×142 4.5 KB

→

image
image1761×160 17 KB

2b.
:warning: Vérifiez ici que le hash de la preimage correspond bien au code: Bytes de la preimage référencée dans la proposal.

image
image1767×410 40.8 KB

2c. Cliquez sur le lien du system.setCode de la preimage pour voir le runtime associé.

2d. Copiez le code: Bytes de ce runtime, c’est votre WASM_BYTES.

image
image1806×612 137 KB

Vous pouvez simplement sélectionner toute la partie visible du bytes hexa ici et le copier, ça va copier tout le byte en entier (attention plusieurs Mo)

3 . Checkout la branche duniter-v2s du network associé à la proposal (par exemple network/gtest-1110), compilez le runtime gtest et vérifiez que le hash blake généré correspond bien à celui sorti par le script.

cargo xtask release runtime build gtest
cat release/srtool_output_gtest.json | grep blake2_256 | jq -r '.runtimes.compressed.blake2_256'

Félicitation, vous êtes sûr à 100% que le code que vous lisez depuis cette branche git correspond bien au runtime proposé au vote.

3 Likes
:police_car_light: Runtime Upgrade Proposal: gtest v1110
GTest - Runtime upgrade 1100
2

Je déterre ce poste.
Je n’avais pas eu beaucoup de réaction hormis quelques likes, concernant mon septissisme face à la doc officielle initial comparé à mon approche.

J’ai donc adapté la doc officielle pour l’aligner avec cette approche dans la branche runtime/gtest-1100: docs/dev/verify-runtime-code.md · runtime/gtest-1100 · nodes / rust / Duniter v2S · GitLab

3 Likes
:police_car_light: Runtime Upgrade Proposal: gtest v1110
3

Très bonne doc mais elle est incomplète, il manque une étape cruciale:

Si les deux hash blake2_256 correspondent, vous avez la certitude que le code
source de la branche git produit bien le runtime proposé au vote. Vous pouvez
voter en confiance.

Vous ne pouvez pas voter en confiance en vérifiant uniquement le hash : ce n’est pas suffisant. Il faut lister tous les commits entre le nouveau git tag et l’ancien (celui correspondant au runtime actuellement déployé) et s’assurer que ces commits contiennent bien les changements annoncés.

Si personne ne vérifie, je peux ajouter une backdoor dans une MR qui me permet de siphonner les fonds d’un autre compte. :stuck_out_tongue:

6 Likes
4

Oui en fait c’est plus clair dans ce présent poste que tout ce parcours de vérification de hash n’est qu’une étape préalable avant de pouvoir commencer à auditer le code et les commits, c’est ce que je dit en dernière phrase de ce topic, qu’il faudrait mieux formuler dans la doc donc:

edit: en fait c’est à peu prêt ce que j’ai mis dans la doc git, mais ce n’est peut être pas assez explicite qu’il faut vérifier le code oui, mais ça me semblait assez évident ^^

2 Likes
5

D’ailleurs tout ce process manuel de vérification de hash pourrait être largement automatisé via une commande gcli qui récupère la proposal et la preimage, build localement, compare les hash, et donne un feu vert ou feu rouge, invitant à auditer le code ou bien alerter d’un problème avec la proposal.

Mais bon il faudrait auditer gcli aussi pour s’assurer qu’il n’y a pas de backdoor non plus, je sais bien, tout dépend du niveau de sécurité sur lequel on se place.

La commande pourrait même donner tous les commits à auditer entre les 2 tags de runtime.

4 Likes
6

Pour aller plus loin, on pourrait dire qu’il faudrait aussi auditer le code de gitlab pour être sûr qu’il ne nous cache pas de commit, et donc plutôt cloner le dépôt en étant sûr que sa version de git ne va pas nous mentir quand on fait git log et que notre système de fichier nous montre bien les fichier qu’on a cloné et pas d’autres, que le driver hdmi de notre écran nous affiche bien ce qu’il faut et pas une image substituée…

Mais il me semble que la commande srtool fournit justement dans les logs un résumé avec des jolis emojis qui montre le hash du code, le hash du proposal, et tout ce qu’il nous faut pour ne rien avoir à faire.

1 Like