Resumo

  • O guia da LACNIC de 10 de agosto baixa fort-1.7.0.experimental.tar.gz, extrai, configura, compila e executa sudo make install no Ubuntu Server 26.04, sem checar hash ou assinatura destacada.
  • A release já oferecia tarball, .asc e fort.keyring. Os três arquivos capturados em 31 de agosto batem com os SHA-256 atuais da API; GnuPG retorna GOODSIG e VALIDSIG sob a impressão digital 8F9ABC7EF3BA565F9DF1578C72160FD57B242967.
  • O resultado protege a relação matemática entre os bytes e a chave fornecida, mas não decide sozinho a autoridade dessa chave: a mesma verificação mostra TRUST_UNDEFINED, e a release aparecia como não imutável na API.
  • Uma instalação controlada precisa guardar release, commit, ativo e digest, fonte independente da chave, parâmetros de compilação, hash do binário instalado, ativação e versão de retorno.

A release estava pronta; o procedimento não estava completo

Em 16 de julho de 2026, a release 1.7.0.experimental ganhou três itens em poucos minutos. O tarball entrou às 03:47:16Z, a assinatura destacada às 03:47:19Z e fort.keyring às 03:51:35Z. O guia da LACNIC viria em 10 de agosto. Não havia, portanto, uma dependência temporal que impedisse o uso dos elementos de verificação.

O documento de oito páginas tem outro mérito temporal: registra uma rota testada para Ubuntu Server 26.04, amd64/x86_64, em vez de repetir instruções genéricas. Segundo o autor do guia, o .deb testado pedia libmicrohttpd12 e libxml2, enquanto o sistema disponibilizava pacotes com nomes diferentes. Por isso a receita compila contra bibliotecas de desenvolvimento nativas. A alegação sobre o pacote vem desse teste documentado; o material analisado não reproduziu o defeito de forma independente.

A sequência baixa fort-1.7.0.experimental.tar.gz, extrai, executa ./configure, usa make -j"$(nproc)" e termina a instalação com sudo make install. Depois consulta fort --version, inspeciona ldd, faz a primeira validação, verifica saídas, configura serviço e RTR e trata da sincronização do relógio.

O cuidado começa depois da extração. Antes dela, não há SHA-256, checksum, referência ao .asc, importação do keyring ou gpg --verify. A menção linguística a assinatura no PDF se aplica a objetos RPKI assinados, não ao pacote de software. O arquivo docs/installation.md fixado no commit da release também ensina download e instalação sem uma verificação de digest ou assinatura destacada.

O teste dos três arquivos dá um resultado forte e limitado

O registro de GitHub diz que a release foi criada em 16 de julho às 01:52:42Z e publicada às 03:45:33Z. A tag anotada aponta para o commit c67d14bcdbc8cbcf100e97c481a8c4ef6eb0ca7e; a API do objeto da tag relata assinatura verificada e válida.

Na captura de 31 de agosto, os digests publicados pela API eram:

Arquivo SHA-256
fort-1.7.0.experimental.tar.gz 70075f82effe5cf9752b13463f50c4379fdf93e5c28bdf6cba04e9621e2288cc
fort-1.7.0.experimental.tar.gz.asc e648b9ff2075c6d78f4bf1a69c96a5b421757432b71f916a3118fb11ffe815ad
fort.keyring 8e4dfee468ad756bc89ffff3894692e87e66ffbd135dc697f3ffbac02116e6a6

As cópias obtidas separadamente correspondem aos três valores. Com o chaveiro fornecido importado em ambiente temporário, a verificação do .asc contra o tarball devolve GOODSIG e VALIDSIG. A impressão digital principal é 8F9ABC7EF3BA565F9DF1578C72160FD57B242967; a assinatura tem timestamp de 16 de julho, 01:55:02Z.

Essa é a defesa mais importante da publicação. O tarball capturado não está sem identidade: bate com o digest atual e carrega uma assinatura matematicamente válida sob a chave fornecida. A evidência não aponta malware, substituição, pacote incorreto, falha de RPKI ou incidente de roteamento.

O mesmo GnuPG devolve TRUST_UNDEFINED e avisa que a chave não estava certificada por uma assinatura confiável no ambiente temporário. Isso não transforma uma assinatura boa em ruim. Mostra que duas decisões foram separadas corretamente. A criptografia liga o arquivo à chave privada correspondente; uma fonte autenticada independente deve dizer quem controla a chave pública e por que ela está autorizada a assinar FORT.

Publicar junto não é provar junto

Há quatro junções que a página visualmente aproxima, mas não funde.

A primeira liga tag e commit. A assinatura relatada como válida autentica a referência a c67d14b…; não atesta automaticamente um arquivo adicionado à área de Releases.

A segunda liga release e bytes do ativo. A API dá nome, horários e digest atual. Também mostrava immutable: false, draft: false e prerelease: false. Não imutável não significa alterado. Significa que o observador deve guardar data e estado, sem usar o hash de hoje como prova universal de downloads passados.

A terceira liga ativo e chave. Uma assinatura destacada válida demonstra posse da chave privada, mas não resolve identidade, autorização, rotação ou revogação. Baixar tarball, assinatura e chaveiro do mesmo canal facilita a operação; não cria uma raiz de confiança independente.

A quarta liga source e executável. O compilador, as flags, os headers e versões de dependências participam do resultado. fort --version e ldd são diagnósticos úteis, mas não preservam o hash do binário nem demonstram build reproduzível. Os documentos não formulam uma alegação de reprodução bit a bit.

O problema do guia não é ter escolhido um tarball comprovadamente ruim. É ter levado apenas um dos três arquivos publicados para dentro do processo e, assim, deixado essas junções para o conhecimento tácito do leitor.

Um recibo operacional cabe ao lado dos comandos

Antes de extrair, a receita poderia fixar tag, commit, nome e URL do ativo; mostrar o SHA-256 esperado e calcular o observado; obter a impressão digital integral por canal autenticado independente; verificar o .asc; e mandar parar diante de qualquer divergência.

Depois do build, um registro curto completaria a cadeia:

Momento Registro mínimo
Release Tag, URL, commit, horário e estado de imutabilidade observado
Download Nome/URL, digest esperado e observado, horário da captura
Assinatura Digests do .asc e keyring, impressão digital, fonte independente, decisão e resultado
Build Sistema, arquitetura, compilador, flags e versões de dependências
Instalação Caminho e hash do binário, versão, hashes de configuração e serviço
Ativação Horário, versão anterior, rollback, rotação/revogação de chave e correções

O registro distribui autoridade. O projeto publica releases e identidade de assinatura; GitHub serve os ativos e declara estado; Ubuntu fornece dependências; a rede escolhe confiança e ativação; LACNIC orienta uma rota testada. Nenhum desses atores controla sozinho toda a cadeia. O documento pode, porém, mostrar onde termina a garantia de cada um.

sudo make install torna essa clareza operacional. A ordem concede autoridade local ao resultado do build. Não há motivo para tratar isso como prova de risco consumado, mas há motivo para registrar exatamente qual resultado recebeu o privilégio.

O alvo é a instrução pública, não o comportamento do operador

Uma equipe pode acrescentar hashes, chaves aprovadas, espelhos internos, pipelines de build e aprovação do binário. A ausência desses passos no PDF não prova que alguém os omitiu na prática.

Da mesma forma, immutable: false não prova mudança do ativo. O digest atual não reconstrói cada download histórico. A assinatura boa com a chave fornecida não estabelece por si só a identidade legal do signatário. Não existe base para alegar comprometimento ou consequência de roteamento.

O recorte também não repete a discussão sobre saída ASPA e negociação RTR. Essa análise observa a interface entre validador e roteador. Aqui a pergunta vem antes: qual executável ganhou autoridade para produzir a informação que será entregue nessa interface?

LACNIC pode corrigir uma lacuna estreita usando materiais que já estavam disponíveis. A mudança não elimina riscos de dependências e não transforma assinatura em confiança automática. Ela permite que um operador repita a decisão, detecte divergência e volte a uma versão cuja identidade também foi preservada.

Fontes