APRENDER. PRATICAR. EVOLUIR.Verificar o conjunto antes dos membros
O primeiro controlo incompleto calcula hashes apenas para app.py e dependency.py. Quando o pacote acrescenta runtime.json, esses hashes continuam corretos e o desvio passa despercebido. A regra mais completa compara primeiro o conjunto exato de nomes e rejeita o membro adicional. Também rejeita duas entradas app.py e um nome ../outside.txt que não pertence ao conjunto permitido. O guião apenas lê a estrutura e os bytes dos ZIP originais; não extrai nem executa conteúdo recebido. Esta é uma regra pedagógica para dois nomes planos, com um limite de tamanho por membro, não um validador seguro para qualquer arquivo. Se um ficheiro novo for legítimo, reconcilia âmbito e evidência antes de alterar a expectativa.
Coerência não autentica a origem
O pacote com dependency.py alterado falha perante o manifesto original. Se o guião também substituir o manifesto pelos hashes do pacote novo, a comparação passa. Não houve assinatura nem verificação de builder: o conjunto apenas ficou coerente consigo próprio. A referência SLSA v1.2 descreve verificação de proveniência e expectativas com uma base de confiança configurada, incluindo a ligação ao artefacto e a identidade do builder. O laboratório não implementa esse processo e não atribui um nível SLSA. Numa receção de fornecedor, identifica a origem confiável da expectativa, o âmbito do documento e quem pode alterá-lo. Guardar um digest ao lado de um pacote recebido não prova que ambos correspondem ao material revisto.
Verificar o que foi efetivamente entregue
candidate.zip passa a comparação inicial com o digest esperado. O guião substitui deliberadamente a origem e só depois copia para incoming.zip. A nova cópia falha a comparação, pelo que promoted.zip conserva os bytes anteriores. Não foi executada uma corrida entre processos; a ordem controlada demonstra a fronteira entre verificar uma origem e copiar mais tarde. Depois, uma cópia correta passa o digest e o conjunto de membros, e os.replace substitui o destino no mesmo filesystem. O resultado local não é uma transação distribuída, não demonstra durabilidade após crash e não protege por si só contra outro escritor entre verificação e uso. Num destino partilhado, esses acessos e a identidade do objeto exigem mecanismos próprios.
Entrega aceite e serviço aceite
A promoção local termina com runtimeAcceptanceProved=false. Isso é deliberado: o ficheiro correto no destino não demonstra que processos o carregaram, que a configuração é compatível ou que os consumidores obtêm o resultado esperado. O plano de release precisa de ativação e validação proporcionais ao serviço. RUN deve conseguir localizar a expectativa confiável, reconhecer rejeição, preservar evidência, escalar um desvio e recuperar um artefacto identificado. A oficina proposta pede essa explicação em inglês, mas ainda não foi executada por um grupo humano. Doze grupos locais passaram duas vezes; revisão especializada e ensaios representativos continuam pendentes. Separa ações sobre entradas, manifesto e entrega, com responsáveis e critérios verificáveis para cada lacuna.
python3 content/labs/release-artifacts/run.py --output /tmp/dr-release-admission.json
# Inspect selfConsistencyIsNotTrustedOrigin and checkBeforeCopyDoesNotBindDeliveredBytes.
# No SLSA verifier, signing service or production approval is implemented.Um manifesto parcial aceita os ficheiros listados e ignora runtime.json; a regra completa rejeita o conjunto inesperado antes da promoção.
Armadilhas comuns
Manifesto recebido como referência independente, hashes como assinatura, cópia como ativação ou verificação anterior como garantia dos bytes futuros.
Tópicos relacionados: Cobertura do manifesto · Autonomia de RUN
Admissão, confiança na origem e aceitação do serviço são controlos distintos; conserva a evidência de cada fronteira e os responsáveis por decisões.
Referência: SLSA v1.2: Build, verifying artifacts · Release management practices 2026-09; scoped GitLab GitHub CodeDeploy and EF Core documentation