Todos los pasos para producir Eclipse Temurin están definidos por pipelines de Jenkins con control de versiones que invocan scripts de construcción almacenados en el repositorio adoptium/temurin-build. Las pipelines y los scripts de construcción están disponibles para que cualquiera pueda verlos y verificarlos, y las ejecuciones en el sistema Jenkins están abiertas al escrutinio. La documentación para usar los scripts de construcción está disponible en el archivo readme del repositorio de construcción.

Adoptium proporciona atestaciones SBOM para la procedencia de las construcciones de Eclipse Temurin. El SBOM está en formato OWASP CycloneDX y está disponible junto con cada uno de nuestros artefactos de lanzamiento de Temurin.

El SBOM incluye la información requerida para recrear la construcción si fuera necesario, incluyendo las etiquetas del repositorio de fuentes utilizadas por el proceso de construcción, el conjunto completo de parámetros utilizados, la salida de los pasos de configuración y otras piezas de información. Estamos evolucionando continuamente los detalles específicos incluidos en el SBOM.

Adoptium refleja el código fuente de la implementación de referencia de Java SE de OpenJDK en nuestro repositorio local de GitHub (p. ej. adoptium/jdk17u). Cada cambio en la fuente que construimos y en los scripts que usamos es rastreado por el sistema de control de versiones de GitHub. Esto asegura un registro del historial de cambios que formaron parte de cada revisión. Cada cambio contiene las identidades de quien lo subió y de los revisores, las marcas de tiempo de las revisiones y el envío, la descripción/justificación del cambio, el contenido del cambio y las revisiones principales. Todos los colaboradores y revisores se someten a una autenticación sólida, y todos los contribuyentes deben ejecutar y cumplir con el Acuerdo de Contribuyente de Eclipse.

Cada revisión inmutable del código bajo nuestro control tiene una referencia única con una vida útil indefinida a través de GitHub (URL del repo + rama/etiqueta/ref + ID del commit). Eclipse Temurin se construye a partir de revisiones etiquetadas de nuestro espejo, y ponemos a disposición archivos comprimidos de la fuente para cada lanzamiento.

Todos los pasos de construcción de Adoptium se ejecutan en nuestro propio servicio de construcción Jenkins gestionado y en el servicio de firma de código de la Fundación Eclipse. Estos servicios realizan las construcciones, generan los SBOM y construyen los instaladores cuando corresponde. La salida de las construcciones se sube a los repositorios de lanzamiento de GitHub por el sistema CI de Jenkins. Ninguna parte del proceso se ejecuta en la estación de trabajo de un desarrollador.

El acceso a los servicios de construcción está cuidadosamente gestionado por el proyecto. El sistema de construcción es lo más abierto posible para permitir el escrutinio de la comunidad sin comprometer la seguridad.

TODO: La autenticidad e integridad de la procedencia pueden ser verificadas por el consumidor. Esto DEBERÍA hacerse mediante una firma digital de una clave privada accesible solo al servicio que genera la procedencia.

Todos los datos de procedencia de Adoptium son generados directamente por los sistemas de construcción y prueba continua del proyecto. Los usuarios del servicio no pueden inyectar ni alterar el contenido de la procedencia. Las firmas de código GNU Privacy Guard (GPG) de Eclipse Temurin son generadas por el servicio de firma de código de Eclipse; otros datos de procedencia, incluyendo la lista de materiales de software, hashes criptográficos, metadatos de construcción, etc., son emitidos directamente por el sistema de construcción del proyecto.

Todas las revisiones del código fuente y su historial de cambios se conservan indefinidamente y no pueden ser eliminadas, excepto cuando estén sujetas a una política establecida y transparente de eliminación, como un requisito legal o una política de la Fundación Eclipse. Este nivel de control de superusuario para cambiar o eliminar el historial es mantenido directa y exclusivamente por la Fundación Eclipse en nombre del proyecto.

Dado que almacenamos todo nuestro código en GitHub, no es posible que las personas eliminen o modifiquen el historial, incluso con la aprobación de múltiples partes, excepto por los administradores de la plataforma de la Fundación Eclipse de confianza con la aprobación de dos partes siguiendo la política de eliminación de la fundación. Las preguntas sobre esta política deben dirigirse a la Fundación Eclipse.

La definición y configuración de la construcción de Adoptium ejecutada por el servicio de construcción se deriva verificablemente de definiciones en archivos de texto almacenados en nuestro sistema de control de versiones.

Las construcciones en entornos efímeros, como un contenedor o una máquina virtual, provisionados exclusivamente para esta construcción y no reutilizados de una construcción anterior, están implementados para las construcciones Linux x86, ARM32 y aarch64. Otras plataformas siguen siendo un trabajo en progreso en el proyecto.

El servicio de construcción de Adoptium garantiza que cada paso de la construcción se ejecute en un entorno aislado libre de la influencia de otras instancias de construcción, ya sean anteriores o simultáneas.

No es posible que una construcción acceda a ningún secreto del servicio de construcción, como la clave de firma de procedencia, ya que estos se almacenan fuera del sistema de construcción y se accede a ellos mediante una llamada remota a un sistema separado. No es posible que dos construcciones que se solapan en el tiempo se influyan mutuamente. Cada paso de la construcción se ejecuta en un entorno de máquina aislado orquestado por el sistema CI de Jenkins, y los pasos de cada construcción se ensamblan mediante el uso de pipelines gestionadas. Las memorias de caché de construcción, donde se utilizan, son puramente direccionables por contenido para evitar manipulaciones.

Continuamos trabajando para asegurar que no sea posible que una construcción persista o influya en el entorno de construcción de una construcción posterior. Cada parte del entorno se especifica en los scripts de construcción. Esto se garantizará ejecutando construcciones en máquinas efímeras en todas partes y comprobando que los resultados sean idénticos.

La información de procedencia del SBOM no puede ser falsificada por los usuarios del servicio, ya que es generada por máquina por el proceso de construcción y firmada criptográficamente por el servicio de firma de código de la Fundación Eclipse para evitar manipulaciones. El servicio de firma de código no es accesible para los colaboradores regulares del proyecto ni para los usuarios de Jenkins.