Registo temporal em blockchain para equipas de software
Por BlockchainSignÚltima atualização
O controlo de versões dá-lhe um histórico detalhado e uma data fraca. Os timestamps dos commits são escritos pela sua máquina e um rebase pode produzir qualquer histórico que deseje. Para qualquer coisa que possa servir de prova, isso é um problema que vale a pena resolver.
A lacuna no seu histórico existente
O Git regista muito, com precisão, para fins de engenharia. Como prova, tem uma fraqueza específica: as datas são escritas por si.
git commit --date, um rebase interativo, uma alteração ao relógio — qualquer um destes produz um histórico que parece totalmente ordinário e diz o que quiser. Isso é aceitável internamente. Perante um adversário motivado, não é muita garantia, e a mesma fraqueza joga contra si quando é quem está a defender.
Os timestamps próprios de um repositório alojado são melhores, mas pertencem a uma plataforma, podem ser perdidos com uma conta e não são verificáveis independentemente por alguém externo.
O que ancorar
Versões (Releases). O hash de um ficheiro de versão ou de um pacote do repositório, registado temporalmente em cada lançamento. Isso fornece um registo à prova de adulteração e datado do exatamente o que foi entregue, o que é útil numa reclamação de infração e igualmente útil na defesa — provar que a sua versão é anterior ao código de que é acusado de copiar é a mesma operação ao contrário.
Estados pré-divulgação. Antes do código ir para um cliente, um auditor, um adquirente ou um agente de custódia. O hash é calculado no seu navegador e apenas o hash é transmitido, o que importa quando o código é o segredo comercial — veja marca vs direitos de autor para código fonte para entender porque a confidencialidade é muitas vezes a proteção que realmente funciona.
Documentos de design e arquitetura. Frequentemente os artefactos mais valiosos e menos protegidos que uma equipa possui.
Capturas de dados. Quando precisa de demonstrar que um conjunto de dados estava num estado específico num momento específico.
Como fazer na prática
Calcule o hash do artefacto, não da árvore de trabalho. O padrão fiável é um ficheiro determinístico:
git archiveougit bundlepara um estado do repositório- Um artefacto de compilação para uma versão
- Um tarball para um diretório, com ordenação reproduzível se quiser que o hash seja repetível
Depois, registre esse ficheiro temporalmente. Armazene o certificado com a versão e anote a tag a que corresponde. Qualquer pessoa pode mais tarde recriar o ficheiro, calcular o hash e comparar com o registo distribuído.
Por que nada é carregado
Para código proprietário, o requisito de confidencialidade é absoluto, e um serviço de registo temporal que quer o ficheiro é um serviço que não pode usar.
Aqui, o ficheiro é hashed no seu navegador com a Web Crypto API e apenas o hash SHA-256 de 64 caracteres é transmitido. Não existe nenhum endpoint que aceite o artefacto. Se preferir gerar o hash o utilizador mesmo, a ferramenta de hash gratuita faz isso localmente e produz saída byte a byte idêntica à do comando shasum -a 256.
O que prova
Que o artefacto existia até esse momento e não mudou. Não prova quem o escreveu, não é uma patente e não regista direitos de autor — veja prova de existência vs prova de autoria.
Os direitos de autor sobre o seu código surgem automaticamente. O que geralmente falta é uma data inatacável, e essa é a lacuna específica que isto preenche.