Leer una atestación de procedencia

4 tareas · 40 min · Principiante

La procedencia es la declaración de quién construyó qué, desde qué fuente y con qué parámetros. Es un documento estructurado, y quien aprende a leerlo sabe en segundos qué se puede afirmar del paquete y qué no. En esta sala abres dos atestaciones consecutivas de enlace-pagos, un paquete de Higuerilla Software, y las lees campo por campo, sin calcular ninguna firma ni huella: son marcadores ficticios para leer la estructura.

0 de 4 · 0%

Objetivo de la sala

Una atestación de SLSA es un enunciado de in-toto (con _type, subject, predicateType y predicate) dentro de un sobre firmado (DSSE). El subject es la lista de artefactos de los que habla, cada uno con su nombre y su huella (digest). El predicateType dice qué clase de afirmación sigue: para la procedencia de SLSA v1.0 es https://slsa.dev/provenance/v1.

El sujeto es lo que enlaza la atestación con un artefacto concreto. Una procedencia correcta pero cuyo sujeto no coincide con la huella del paquete que tienes delante no habla de ese paquete.

Responde para continuar

¿Para qué sirve el campo subject de una atestación de procedencia?

Para identificar el artefacto del que habla la atestación por su huella, y compararla con el recibido Para enumerar las dependencias que se usaron al construir el artefacto y las versiones de cada una Para indicar quién firmó la atestación y con qué clave, de modo que se pueda validar la firma después

Dentro del predicado, runDetails.builder.id identifica al constructor: la plataforma o el ejecutor que realizó la construcción. Es el campo con el que se decide a cuánto se puede fiar la atestación, porque el nivel que se le reconoce depende de quién la generó. El resto de runDetails aporta el rastro de esa ejecución: identificador de la invocación y los momentos de inicio y fin.

Abre atestaciones/enlace-pagos-3.4.1.txt.

Responde para continuar

Escribe el nombre del ejecutor que construyó enlace-pagos 3.4.1 (el tramo antes de @v1 en builder.id).

Ver pista de ayuda

Está al final de la ruta que sigue a builder.id.

buildDefinition describe cómo se construyó. Tiene el buildType (qué clase de construcción es y cómo interpretar sus parámetros), los externalParameters, los internalParameters y las resolvedDependencies. La diferencia entre los dos tipos de parámetros es de quién los controla: los externos son lo que quien pide la construcción puede influir (la rama, el flujo, una entrada manual) y por eso quien consume debe revisarlos todos; los internos los fija la plataforma y quien pide la construcción no los decide.

Responde para continuar

¿Por qué quien consume debe revisar todos los externalParameters de una procedencia?

Porque los controla quien pide la construcción, y uno inesperado puede cambiar lo que se construyó Porque son el registro de tiempos de la ejecución y sirven para detectar construcciones demasiado lentas Porque son los que la plataforma fija y cambian de una versión de la plataforma a la siguiente

Una buena costumbre al leer procedencias es compararlas. Si dos versiones consecutivas se construyen con el mismo flujo, sus parámetros externos deberían ser los mismos salvo lo que cambia por definición (la etiqueta de versión). Un parámetro que aparece o desaparece merece una explicación.

Compara las atestaciones de enlace-pagos 3.4.0 y 3.4.1.

Responde para continuar

Escribe el nombre del parámetro externo que aparece en la procedencia de 3.4.1 y no en la de 3.4.0.

Ver pista de ayuda

Compara los externalParameters de los dos archivos línea por línea.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 El sujeto: de qué artefacto habla Lab

2 Quién construyó Lab

3 Parámetros externos y parámetros internos Lab

4 Qué cambió entre dos versiones Lab

Whoami-Labs Pro utiliza cookies