Como registar temporalmente um lançamento de software
Por BlockchainSignPublicado a

O controlo de versões oferece um histórico excelente e uma data fraca. Ancorar um lançamento resolve o segundo problema em cerca de um minuto por versão.
Por que as datas do git não são suficientes
Os carimbos temporais dos commits são escritos pela máquina que os efetua. Uma rebase interativa, uma alteração no relógio ou a flag --date comum podem produzir qualquer histórico desejado, e o resultado parece completamente normal.
Isso é aceitável internamente. Como prova, é frágil, e essa fraqueza atua em ambos os sentidos — é igualmente inútil quando se está a defender-se de uma alegação em vez de a formular.
Os próprios carimbos temporais de uma plataforma alojada são melhores, mas pertencem à plataforma, desaparecem com a conta, e um terceiro não os pode verificar independentemente.
O que ancorar
Não a árvore de trabalho. Um artefato determinístico cujos bytes possa reproduzir mais tarde:
git archive --format=tar.gz -o release-v1.4.0.tar.gz v1.4.0
ou um bundle, que captura o histórico bem como o conteúdo:
git bundle create release-v1.4.0.bundle v1.4.0
ou a própria saída da compilação, se a sua compilação for reproduzível.
Depois, faça o hash desse ficheiro e registre-o temporalmente.
Os passos
- Crie o artefato a partir da tag, não do seu diretório de trabalho.
- Faça o hash — shasum -a 256, ou a ferramenta no browser, que produz a mesma saída.
- Registe o hash temporalmente. O ficheiro é processado no seu browser e apenas o hash é transmitido, o que importa quando o código é proprietário.
- Guarde o certificado junto do lançamento, e registe a qual tag corresponde.
- Mantenha o artefato, byte a byte. Regenerá-lo mais tarde pode não reproduzir os mesmos bytes, pois os formatos de ficheiro guardam carimbos temporais e ordem.
Este último ponto apanha muitas pessoas desprevenidas. Um tar.gz regenerado a partir da mesma tag numa máquina diferente é frequentemente um ficheiro diferente. Guarde aquele que fez o hash.
Tornar reproduzível, se quiser saltar o passo 5
Ficheiros determinísticos são alcançáveis com esforço — tempos de modificação fixos, entradas ordenadas, nível de compressão definido. Se a sua compilação já for reproduzível, fazer o hash da saída significa que qualquer pessoa pode regenerar e verificar independentemente, o que é mais forte do que pedir confiança na cópia armazenada.
Se não for, manter o artefato é totalmente razoável e muito mais barato do que tornar a compilação determinística apenas para este fim.
O que isto lhe dá
| Pergunta | Respondida por |
|---|---|
| O que enviámos? | O artefato |
| Quando o enviamos? | O carimbo temporal |
| Quem o escreveu? | Commits e tags assinados |
| Mudou desde então? | O carimbo temporal |
| É autêntico? | Uma tag assinada, mais o carimbo temporal |
A assinatura e o carimbo temporal complementam-se bem e respondem a perguntas diferentes. Uma tag assinada prova quem a criou e que o conteúdo não foi modificado; a data da assinatura continua a ser aquela que a máquina do signatário afirmou. O carimbo temporal fixa o tempo independentemente. Faça ambos nos lançamentos importantes.
Quando vale a pena fazer
Lançamentos públicos onde a data possa importar numa questão de licenciamento ou infração.
Antes de uma auditoria, depósito em custódia ou aquisição — um registo datado do exatamente o que foi entregue.
Antes de divulgar código a um cliente ou parceiro, que é também o momento em que o código está mais exposto como segredo comercial. Ver marca vs direitos de autor para código fonte.
Quando usa uma licença permissiva e quer um registo da sua versão anterior às alegações de um fork.
Não vale a pena para cada commit. O objetivo é um pequeno número de âncoras datadas em torno de estados que possam precisar de defesa, não cerimónia no trabalho ordinário.
Para a versão mais ampla deste argumento, ver registo temporal em blockchain para equipas de software.