Construcciones Gitian reproducibles... pero no el mismo hash que bitcoincore.org

Hice una reconstrucción de 0.20.1 y obtuve los mismos resultados que tú. Esto indicaría que una dependencia de compilación se ha actualizado para producir resultados ligeramente diferentes a la versión que estaba en uso en el momento del lanzamiento. Las versiones de dependencia de compilación están ancladas a diferencia de las dependencias de software reales. IIRC, esto es común para las compilaciones gitian y el intento de reconstruir incluso versiones más antiguas dará como resultado discrepancias similares.

Hay trabajo en curso para pasar a un sistema de compilaciones reproducibles diferente llamado guix. Este sistema de compilación fijará las versiones de dependencia exactas, junto con la opción de compilar toda la cadena de herramientas desde cero. Esto debería permitir compilaciones totalmente reproducibles que se pueden replicar en cualquier momento.

Aquí hay una explicación más detallada de este desajuste en particular, copiado de mi respuesta en este número de GitHub .

Si observa los resultados de compilación de Gitian, verá un archivo llamado bitcoin-0.20.1-x86_64-linux-gnu-debug.tar.gz. Si descomprime este archivo, habrá *.dbgarchivos, por ejemplo, bitcoind.dbgy bitcoin-qt.dbg. Estos *.dbgarchivos contienen los datos de depuración de sus respectivos binarios, es decir, bitcoind.dbgcontienen datos de depuración de bitcoind.

Para asegurarse de usar el dbgarchivo correcto con el binario correcto, gcc incrusta una suma de verificación del dbgarchivo dentro del propio binario. Esto significa que bitcoindcontiene una suma de comprobación de bitcoind.dbg. Esto es para evitar intentar depurar bitcoindcon otro dbgarchivo. Por ejemplo, si intenta decirle a gdb que el bitcoin-qt.dbgarchivo contiene los símbolos de depuración para bitcoind, detectará que no los contiene y no intentará cargar los símbolos de depuración de bitcoin-qt.dbg.

Los símbolos de depuración se compilan inicialmente en el bitcoindbinario, pero más tarde, durante la compilación de Gitian, se eliminan y se colocan en el bitcoind.dbgarchivo. Sin embargo, debido a que se compilan bitcoindinicialmente, los símbolos de depuración tienen un efecto en la identificación de compilación que gcc incrusta en el binario. El ID de compilación es un hash del binario compilado, incluidos los datos de depuración.

Entonces, el resultado final es que el binario publicado contiene dos compromisos con los símbolos de depuración, pero en realidad no los contiene.

Puede leer más sobre estos archivos de depuración separados aquí: https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html

El quid de este problema es que los símbolos de depuración de las versiones recientes de Gitian difieren de los símbolos de depuración que se generaron para la versión original. Esto significa que tanto el ID de compilación como la suma de verificación del símbolo de depuración que encontramos dentro bitcoindson diferentes. Esto da como resultado que los bitcoindvalores hash sean diferentes (así como todos los demás binarios). Y, por supuesto, eso hace que los hashes del archivo tar sean diferentes.

Aquí está la diferencia de los binarios que genera diffoscope:

--- bitcoind
+++ /mnt/archive/bitcoin/bitcoin-binaries/0.20.1/bitcoin-0.20.1/bin/bitcoind
├── readelf --wide --notes {}
│ @@ -1,15 +1,15 @@
│  
│  Displaying notes found in: .note.ABI-tag
│    Owner                Data size     Description
│    GNU                  0x00000010    NT_GNU_ABI_TAG (ABI version tag)        OS: Linux, ABI: 3.2.0
│  
│  Displaying notes found in: .note.gnu.build-id
│    Owner                Data size     Description
│ -  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 6b464617f7f91fd270ac86f43ef4a58eeeedff19
│ +  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 3a439a31a5157ff7052ed310050df5643a02ea3f
│  
│  Displaying notes found in: .note.stapsdt
│    Owner                Data size     Description
│    stapsdt              0x00000036    NT_STAPSDT (SystemTap probe descriptors)        Provider: libstdcxx
│      Name: throw
│      Location: 0x00000000006e550d, Base: 0x000000000086d140, Semaphore: 0x0000000000000000
│      Arguments: 8@%rdi 8@%rsi
├── readelf --wide --decompress --hex-dump=.gnu_debuglink {}
│ @@ -1,5 +1,5 @@
│  
│  Hex dump of section '.gnu_debuglink':
│    0x00000000 62697463 6f696e64 2e646267 00000000 bitcoind.dbg....
│ -  0x00000010 b25ceebb                            .\..
│ +  0x00000010 114d519d                            .MQ.

Como puede ver, solo hay dos diferencias aquí, una en la ID de compilación y otra en la .gnu_debuglinksección. De la documentación que vinculé anteriormente, podemos ver que esta .gnu_debuglinksección tiene la primera línea es el nombre del archivo de depuración seguido de suficientes 0 bytes para completar un límite de 4 bytes. La segunda línea es la suma de comprobación CRC de 4 bytes. Y es esta suma de comprobación de CRC la que difiere.

Entonces, ¿por qué los símbolos de depuración difieren aquí? Nuevamente, el difoscopía puede ayudarnos un poco.

--- bitcoind.dbg
+++ /mnt/archive/bitcoin/bitcoin-binaries/0.20.1/bitcoin-0.20.1/bin/bitcoind.dbg
├── readelf --wide --notes {}
│ @@ -1,15 +1,15 @@
│  
│  Displaying notes found in: .note.ABI-tag
│    Owner                Data size     Description
│    GNU                  0x00000010    NT_GNU_ABI_TAG (ABI version tag)        OS: Linux, ABI: 3.2.0
│  
│  Displaying notes found in: .note.gnu.build-id
│    Owner                Data size     Description
│ -  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 6b464617f7f91fd270ac86f43ef4a58eeeedff19
│ +  GNU                  0x00000014    NT_GNU_BUILD_ID (unique build ID bitstring)     Build ID: 3a439a31a5157ff7052ed310050df5643a02ea3f
│  
│  Displaying notes found in: .note.stapsdt
│    Owner                Data size     Description
│    stapsdt              0x00000036    NT_STAPSDT (SystemTap probe descriptors)        Provider: libstdcxx
│      Name: throw
│      Location: 0x00000000006e550d, Base: 0x000000000086d140, Semaphore: 0x0000000000000000
│      Arguments: 8@%rdi 8@%rsi
├── readelf --wide --debug-dump=info {}
│┄ error from `readelf --wide --debug-dump=info {}`:
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│┄ readelf: Error: /build/binutils/src/binutils-gdb/binutils/dwarf.c:1989: read LEB value is too large to store in destination variable
│ @@ -85052,36 +85052,36 @@
│      <29607>   DW_AT_decl_line   : 124
│      <29608>   DW_AT_decl_column : 16
│      <29609>   DW_AT_type        : <0x28761>
│      <2960d>   DW_AT_data_member_location: 12
│   <2><2960e>: Abbrev Number: 30 (DW_TAG_member)
│      <2960f>   DW_AT_name        : (indirect string, offset: 0x13aaf): __kind
│      <29613>   DW_AT_decl_file   : 108
│ -    <29614>   DW_AT_decl_line   : 148
│ +    <29614>   DW_AT_decl_line   : 128
│      <29615>   DW_AT_decl_column : 7
│      <29616>   DW_AT_type        : <0x287a6>
│      <2961a>   DW_AT_data_member_location: 16
│   <2><2961b>: Abbrev Number: 30 (DW_TAG_member)
│      <2961c>   DW_AT_name        : (indirect string, offset: 0x7a535): __spins
│      <29620>   DW_AT_decl_file   : 108
│ -    <29621>   DW_AT_decl_line   : 154
│ +    <29621>   DW_AT_decl_line   : 134
│      <29622>   DW_AT_decl_column : 3
│      <29623>   DW_AT_type        : <0x2879a>
│      <29627>   DW_AT_data_member_location: 20
...

Hay muchos más resultados que no he incluido porque son casi todos iguales.

Ahora bien, esto no es muy útil, pero podemos ver que para un montón de funciones, el número de línea de esa función difiere en 20 líneas.

Para obtener más información, usé dwarfdump. Esto es lo que dice para la nueva compilación de las dos funciones que muestro en difscope (las funciones son __kind y __spins).

0x0002960e:     DW_TAG_member
                  DW_AT_name    ("__kind")
                  DW_AT_decl_file       ("/usr/include/x86_64-linux-gnu/bits/thread-shared-types.h")
                  DW_AT_decl_line       (148)
                  DW_AT_decl_column     (0x07)
                  DW_AT_type    (0x000287a6 "int")
                  DW_AT_data_member_location    (0x10)

0x0002961b:     DW_TAG_member
                  DW_AT_name    ("__spins")
                  DW_AT_decl_file       ("/usr/include/x86_64-linux-gnu/bits/thread-shared-types.h")
                  DW_AT_decl_line       (154)
                  DW_AT_decl_column     (0x03)
                  DW_AT_type    (0x0002879a "short int")
                  DW_AT_data_member_location    (0x14)

Como puede ver por el nombre de archivo dado, estas funciones provienen de las bibliotecas instaladas en el sistema. Estos parecen ser encabezados para la implementación de gcc de c ++ stdlib.

Entonces, lo que sucedió es que libstdc ++ se actualizó en Ubuntu. Independientemente de las actualizaciones que hayan ocurrido, se ha movido algún código en algunos archivos de encabezado que Bitcoin Core incluye en su uso de c ++ stdlib. A su vez, compilar con esos encabezados actualizados da como resultado diferentes símbolos de depuración porque las declaraciones de funciones se han movido en esos archivos de encabezado. Esto da como resultado que gcc calcule una ID de compilación diferente y una suma de verificación de CRC diferente para los símbolos de depuración. Esto finalmente da como resultado que los binarios finales sean ligeramente diferentes, lo que hace que los valores hash no coincidan.

Siempre que la imagen del sistema operativo subyacente sea susceptible de cambios, no obtendrá un sistema de compilación reproducible que garantice la reproducibilidad durante un largo período de tiempo. Si el sistema operativo puede actualizar las cadenas de herramientas del compilador, las versiones de libc y cualquier herramienta que se use durante una compilación gitian, se esperan cambios en el resultado en el futuro. Dado que este es el caso dado que gitian está basado en ubuntu, y los parches aún se envían a versiones anteriores de ubuntu, esto es de esperarse después de un tiempo.