bitcoin core : Reproductible Gitian Builds .. mais pas le même hachage que bitcoincore.org


J’ai fait une reconstruction de 0.20.1 et j’obtiens les mêmes résultats que vous. Cela indiquerait qu’une dépendance de construction a été mise à jour pour produire des résultats légèrement différents de la version utilisée au moment de la publication. Les versions de dépendance de construction sont épinglées contrairement aux dépendances logicielles réelles. IIRC, c’est courant pour les versions gitian et tenter de reconstruire des versions encore plus anciennes entraînera des incompatibilités similaires.

Des travaux sont en cours pour passer à un autre système de construction reproductible appelé guix. Ce système de construction épinglera les versions exactes des dépendances, ainsi que la possibilité de construire l’ensemble de la chaîne d’outils à partir de zéro. Cela devrait permettre des versions entièrement reproductibles qui peuvent être répliquées à tout moment.

Voici une explication plus détaillée de cette incompatibilité particulière, copiée de ma réponse dans ce problème GitHub.

bitcoin core : Reproductible Gitian Builds .. mais pas le même hachage que bitcoincore.org

Si vous regardez les résultats de la construction gitian, vous verrez un fichier nommé bitcoin-0.20.tar.gz. Si vous décompressez ce fichier, il y aura des fichiers *.dbg, par exemple bitcoind.dbg et bitcoin-qt.dbg. Ces fichiers *.dbg contiennent les données de débogage pour leurs binaires respectifs, c’est-à-dire que bitcoind.dbg contient les données de débogage pour bitcoind.

gcc intègre une somme de contrôle du fichier dbg dans le binaire lui-même. Cela signifie que bitcoind contient une somme de contrôle de bitcoind.dbg. Cela permet d’éviter toute tentative de débogage de bitcoind avec un autre fichier dbg. Par exemple, si vous essayez de dire à gdb que le fichier bitcoin-qt.dbg contient les symboles de débogage pour bitcoind, il détectera que ce n’est pas le cas et n’essaiera pas de charger les symboles de débogage depuis bitcoin-qt.dbg.

Les symboles de débogage sont initialement compilés dans le binaire bitcoind, mais plus tard au cours de la construction gitian, ils sont supprimés et placés dans le fichier bitcoind.dbg. Cependant, comme ils sont initialement compilés dans bitcoind, les symboles de débogage ont un effet sur l’ID de construction que gcc intègre dans le binaire. L’ID de construction est un hachage du binaire compilé, y compris les données de débogage.

Ainsi, le résultat final est que le binaire publié contient deux engagements envers les symboles de débogage, mais ne les contient pas lui-même.

:///gdb/onlinedocs/gdb/Separate-Debug-Files.html

Le nœud de ce problème est que les symboles de débogage des versions récentes de gitian diffèrent des symboles de débogage générés pour la version d’origine. Il en résulte alors que les hachages bitcoind sont différents (ainsi que tous les autres binaires). Et bien sûr, cela fait que les hachages du fichier tar sont différents.

Voici le diff des binaires générés par diffoscope  :

  • – bitcoind +++ /mnt/archive/bitcoin/bitcoin-binaries/0.20.1/bitcoin-0.20.1/bin/,15 +1,:.note. Linux, ABI : 3.2.0 │ │ Affichage des notes trouvées dans :. note.gnu.: │ │ Displaying notes found in :. Remarque. LibStDCXX │ Nom : Throw │ Lieu : 0x00000000006E550D, base : 0x00000000000086d140,% RSIC : 0x0000000000000000 │ Arguments: 8 ├% RDI 8 ├ ├% RSI : 0x0000000000000000 │ ├% RDI ├ ├ ├ ├ ├ ├ ├ ├ ├% RDI 8 readelf –wide –decompress –hex-dump=.5 +1.: │ 0x00000000 62697463 6f696e64 2e646267 00000000 bitcoind.dbg. │ – 0x00000010 b25ceebb.\. │ + 0x00000010 114d519d.MQ.
  • Comme vous pouvez le voir, il n’y a que deux différences ici, une dans l’ID de construction et une dans la section.. D’après la documentation que j’ai liée plus tôt. La deuxième ligne est la somme de contrôle CRC de 4 octets. Et c’est cette somme de contrôle CRC qui diffère.

    Alors pourquoi les symboles de débogage diffèrent-ils ici ? Encore une fois.

  • — bitcoind.dbg +++ /mnt/archive/bitcoin/bitcoin-binaries/0.20.1/bitcoin-0.20.1/bin/bitcoind.15 +1,:.note. Linux, ABI : 3.2.0 │ │ Affichage des notes found in :.note.gnu. │ + GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID : │ │ Displaying notes Trouvé dans:.note. libstdcxx │ Nom : Throw │ Lieu : 0x00000000006e550d, base : ,: │ │ @ @ @ @ to 8 rsi ├── readelf –wide –debug-dump=info {} │┄ erreur de `readelf –wide –debug-dump=info {}`  : │┄ readelf  : Erreur  : /build/binutils/src/binutils-gdb/binutils/dwarf.c :1989  : la valeur LEB lue est trop grande pour être stockée dans la variable de destination │┄ readelf  : erreur  : /build/binutils/src/binutils-gdb/binutils/dwarf.c :1989  : la valeur LEB lue est trop grande pour être stockée dans la variable de destination variable de destination │┄ readelf  : Erreur  : /build/binutils/src/binutils-gdb/binutils/dwarf.c :1989  : la valeur LEB lue est trop grande pour être stockée dans la variable de destination │┄ readelf  : Erreur  : /build/binutils/src /binutils-gdb/binutils/dwarf.c :1989  :: │ DW_AT_data_member_location  : 12 │   : numéro d’abréviation  :: (chaîne indirecte, décalage  : 0x13aaf)  :< 29613>108 │ – DW_AT_decl_li ne :: 128 │ DW_AT_decl_column :: │ DW_AT_data_member_location : 16 │ Numéro : 30 Abrév. (chaîne indirecte, décalage : 0x7a535) :: 108 │ – dw_at_decl_line :: 134 │ :: 20..
  • Il y a beaucoup plus de sorties que je n’ai pas incluses car c’est à peu près la même chose.

    Maintenant, ce n’est pas très utile. le numéro de ligne de cette fonction diffère de 20 lignes.

    Pour obtenir plus d’informations, j’ai utilisé dwarfdump.

    0x0002960e  :/usr/include//bits/thread-shared-types./usr/include//bits/thread-shared-types.

    Comme vous pouvez le voir par le nom de fichier donné, ces fonctions proviennent de bibliothèques installées sur le système. Ceux-ci semblent être des en-têtes pour l’implémentation par gcc de la stdlib c++.

    Donc, ce qui s’est passé, c’est que libstdc++ a été mis à jour dans Ubuntu. Quelles que soient les mises à jour, du code a été déplacé dans certains fichiers d’en-tête que Bitcoin Core inclut dans son utilisation de la stdlib c++. À son tour, la compilation avec ces en-têtes mis à jour entraîne des symboles de débogage différents car les déclarations de fonction ont été déplacées dans ces fichiers d’en-tête. Cela se traduit alors par le calcul par gcc d’un ID de construction différent et d’une somme de contrôle CRC différente pour les symboles de débogage. Il en résulte enfin que les fichiers binaires finaux sont légèrement différents, ce qui entraîne une non-concordance des hachages.