¿Qué son exactamente las "compilaciones verdaderamente reproducibles"?

¿Qué son exactamente? ¿Por qué son importantes en el dominio de la entrega continua?

Contexto: He visto en uno de los comentarios de (creo que reddit) que las compilaciones verdaderamente reproducibles siguen siendo una tecnología en investigación, y es muy difícil de crear.

Entonces, quería saber por qué son tan difíciles de crear.

¿Qué son exactamente?

Aquí hay una cita de reproducible-builds.org :

Las compilaciones reproducibles son un conjunto de prácticas de desarrollo de software que crean una ruta verificable desde el código fuente legible por humanos hasta el código binario utilizado por las computadoras.

¿Por qué son importantes?

En mi opinión, la forma más fácil de explicar su importancia es considerarlos como una variación de un procedimiento de respaldo.

Como ejemplo:

• Suponga que una empresa que usa (depende) de algún paquete de software con licencia de algún proveedor de software. Mientras que la empresa solo obtiene los ejecutables, no las fuentes, etc. que se usaron para crear esos ejecutables.

• Todo va bien, pero en algún momento algo sale mal con el proveedor de software, por ejemplo, quebran (por ejemplo, quiebra).

• Esto puede exponer un riesgo para el negocio (a largo plazo). Es decir, si no hay un procedimiento / acuerdo establecido para que la empresa obtenga acceso (legal) a todas las fuentes, documentación, procedimientos de compilación, etc., relacionados con cualquier cosa del proveedor de software utilizado (en aquellos días) cuando los ejecutables (utilizados por la empresa) fueron creados (y enviados a la empresa).

• Ahí es donde " Software Escrow " viene al rescate: si existe tal acuerdo, uno podría pensar que a través de un tercero, aún sería posible que la empresa tenga acceso a " lo que se utilizó " para poder reproducir los ejecutables, de modo que a partir de ahí, la empresa podría tener la oportunidad de continuar utilizando ese software y, cuando sea apropiado, comenzar a mantenerlo ellos mismos (solo para administrar su propio negocio).

• Sin embargo, " lo que se utilizó " en la viñeta anterior es la parte más difícil para que esto funcione. Requiere que el tercero realice validaciones apropiadas por adelantado. Y créanme, toma un tiempo antes de que pueda recrear un ejecutable para el cual puede probar que, aparte de (por ejemplo) la fecha del enlace, es una combinación perfecta con lo que el proveedor de software entrega al agente de software.

¿Y por qué son tan difíciles de crear?

Si la muestra anterior aún no es lo suficientemente clara, imagine que es mi agente de custodia de software, dígame lo que necesita como entrada para recrear una copia del software con licencia de mi cliente. ¿Consíguelo? ¿No olvidó verificar qué versión de mi compilador, tal vez mi sistema operativo, opciones de compilación / enlace, versiones de componentes reutilizables (incluye), bibliotecas, etc.

Para proporcionar un ejemplo práctico de un intento de crear una compilación verdaderamente repetible, considere lo siguiente:

Una tubería de compilación que comienza con un repositorio git para el que ningún usuario puede volver a escribir el historial o eliminar ramas no fusionadas.

El primer paso de "compilación" después de verificar el código fuente es girar un contenedor que contiene todas las dependencias de tiempo de compilación.

La salida del contenedor de tiempo de compilación en ejecución es un contenedor que contiene el binario compilado.

Más importante para la repetibilidad de la compilación, las siguientes etiquetas se agregan al contenedor final:

• El hash exacto del código fuente en el repositorio original y la url del repositorio git y una instantánea de bola de alquitrán del código que se carga en un repositorio de artefactos.
• La versión exacta del contenedor de compilación que se utilizó para ejecutar la compilación.
• La versión exacta de la imagen base original en la que se cargó el binario.
• Los valores de todas las variables de tiempo de construcción utilizadas para crear el binario.
• La versión de Docker con la que se construyeron los tres contenedores, así como la versión con la que se ejecutaban cuando se construyeron.

Al agregar todos estos metadatos podemos asegurarnos de que en cualquier momento en el futuro podamos extraer el conjunto exacto de dependencias de compilación (a través del contenedor de compilación), compilar el binario con un conjunto exacto de pasos conocidos (consagrados en el contenedor de compilación ) y empaquete esto en otra imagen base conocida con todas las dependencias de tiempo de ejecución (usando la etiqueta de imagen base) y todo esto puede basarse en la versión correcta exacta del código fuente basada en la etiqueta en el contenedor.

Teóricamente, esto debería darnos la capacidad de reproducir exactamente una versión de compilación.

La importancia de esto es que nos permite ver lo que se está ejecutando en la producción e, incluso si todo ha progresado significativamente en las versiones, retroceder y extraer la versión del código, la imagen base y el contenedor de compilación utilizado originalmente para que podamos, por ejemplo , aplique una revisión a esa versión antes de reconstruir exactamente como antes para que podamos volver a implementar sabiendo que es exactamente el mismo artefacto con el único delta que es la revisión.