Resumo

  • O firmware 5130 acrescentou a arquitetura openwrt-hwprobe, destinada a permitir firmware de nova geração em sondas físicas existentes; o plano trimestral ainda classifica o programa mais amplo de empacotamento OpenWrt como em andamento.
  • A documentação pública já expõe controles relevantes: branch de produção, convenção de versões, chaves públicas por geração, notas de versão, diagnóstico com checksums e campo de versão nas sondas.
  • Esses elementos não fazem do número 5130 uma prova completa do commit, do ambiente OpenWrt, dos bytes assinados, da elegibilidade do equipamento, do resultado da onda e do rollback.
  • Não há alegação de comprometimento, assinatura indevida, falha de atualização, indisponibilidade ou medição corrompida. A proposta é um manifesto público agregado apoiado por um registro protegido por dispositivo.

A etiqueta chega depois da custódia

Quando uma sonda informa que roda o firmware 5130, o dado parece direto. Mas ele é o resultado final de decisões tomadas por atores diferentes. Revisores aprovam código. A cadeia OpenWrt escolhe SDK, feeds, configurações e perfil de destino. Um processo produz o binário. Uma autoridade de assinatura legitima aqueles bytes. O serviço de atualização define quem pode recebê-los. A sonda verifica, reinicia, se reconecta e volta a medir.

Cada etapa tem seu próprio objeto de prova. O commit identifica o código. O manifesto de build identifica as entradas. O hash identifica o artefato. A assinatura demonstra autorização sobre o artefato. A regra de coorte delimita os equipamentos. O recibo do dispositivo registra o que ocorreu. O teste funcional diz se a sonda voltou a cumprir sua finalidade.

A nota do firmware 5130 mostra por que não se deve resumir tudo ao número. Ela reúne mudanças para todas as plataformas, hardware, sondas de software e integração contínua. No hardware, introduz openwrt-hwprobe para firmware de nova geração em equipamentos existentes, substitui bases separadas por uma base comum, acrescenta impressão de checksums para depurar arquivos de atualização, corrige uma falha de atualização do aplicativo e recupera configuração estática salva.

São mudanças de construção, inicialização, registro e operação. Duas sondas podem exibir 5130 e ainda assim ter atravessado momentos ou coortes diferentes. Só um encadeamento explícito diz se receberam o mesmo artefato e passaram pelo mesmo critério de aceitação.

Código publicado não é sinônimo de frota migrada

O plano do terceiro trimestre afirma que o RIPE NCC continua tornando o processo de firmware mais simples e trabalha em OpenWRT para sondas de hardware. O status é “em andamento”. Já a nota 5130 mostra uma arquitetura entregue.

As duas afirmações são compatíveis. Um programa pode entregar uma peça antes de terminar. O erro seria concluir que todo o parque foi migrado porque a arquitetura entrou numa versão, ou concluir que nenhuma mudança operacional existe porque o plano permanece aberto.

Entre fonte e frota há estados importantes: mesclado, construído, aprovado, assinado, liberado para canário, elegível para onda ampla, oferecido, instalado, reconectado, testado, adiado, pausado e revertido. Tratar tudo como “lançado” apaga decisões que depois se tornam decisivas.

Essa separação também evita injustiças. Uma sonda offline não é uma falha de pacote. Um adiamento pode ser uma medida prudente. Um rollback com critério claro é sinal de controle. A contabilidade correta precisa preservar essas categorias.

O repositório já distingue autoridades

O guia BUILD fixado no commit analisado chama master de branch pronta para produção e diz que o firmware de hardware é construído dela. Ele separa testing, devel e branches de tickets, e define como versões de produção os números divisíveis por dez.

Essas convenções são úteis. O branch informa maturidade, e o número informa intenção de lançamento. Mas master se move. Para reconstruir um build histórico, é necessário guardar o commit efetivamente consumido. O próprio guia oferece essa possibilidade: o feed OpenWrt pode seguir um branch ou ser preso a ^commit.

O Makefile OpenWrt fixado deriva PKG_VERSION do arquivo VERSION, copia o código para o diretório de build e inclui arquivos de chave pública de desenvolvimento, teste e produção para as gerações v3, v4 e v5. O pacote de hardware só deve ser instalado sob orientação do RIPE NCC.

Portanto, maturidade do código, identidade da versão, autenticidade do pacote, compatibilidade da geração e permissão operacional são controles distintos. A interface pode representá-los com uma etiqueta; o registro de custódia deve mantê-los separados.

O commit não congela o OpenWrt inteiro

Fixar o commit do RIPE Atlas é necessário, mas ainda permite que OpenWrt, SDK, compilador, feeds, patches e opções variem. Dois builds podem começar no mesmo código e gerar bytes diferentes.

Um manifesto verificável deve guardar o commit; versões de OpenWrt e SDK; travas de dependências; configuração; perfis de hardware; hashes do artefato e do próprio manifesto; impressão ou classe não secreta da chave pública de produção; papel aprovador; número e nota da versão.

Isso não exige publicar a chave privada nem prometer reprodução byte a byte em qualquer máquina. Exige identificar quais bytes a versão pretendia distribuir e por que uma variante, caso exista, é diferente.

A nota 5130 registra que checksums adicionais facilitam a investigação de arquivos de atualização. A integridade do artefato já é uma necessidade de engenharia. O recibo proposto apenas leva essa lógica além do build, até assinatura, liberação e resultado.

A palavra “provavelmente” descreve uma frota real

A documentação Gerenciando sua sonda diz que, ao se conectar, ela provavelmente atualizará para o firmware mais recente e iniciará medições predefinidas. A página detalhada mostra a versão. A API pública oferece filtro por firmware_version.

Essa observação é valiosa, mas “provavelmente” deixa espaço para sondas offline, reconexão tardia, incompatibilidade, canários, adiamentos, falhas e reversões. A data da nota não é a data de transição de todos os equipamentos.

Publicar históricos individuais não é solução. Localização, rede e falha específica podem identificar o anfitrião ou ampliar risco. É melhor separar duas camadas.

Na camada protegida ficam: dispositivo, geração, versão anterior e posterior, hash oferecido, elegibilidade, horários, verificação, boot, conexão, testes de medição, erro, nova tentativa, autorização de rollback e exceção.

Na camada pública ficam agregados por geração ou coorte suficientemente ampla: elegíveis, tentativas, sucessos, adiamentos, falhas e rollbacks; janela; denominador; versão da suíte de testes; regra de aprovação; estado ativo, pausado, substituído ou retirado.

O denominador não pode ficar implícito. “99% atualizado” é ambíguo sem dizer se equipamentos offline ou não elegíveis entram na conta. “Nenhuma falha” é enganoso se os casos adiados não foram tentados.

Uma sonda precisa medir, não apenas iniciar

O critério de aceitação deve separar instalação, reconexão e validação da medição. Uma sonda que inicializa mas perde identidade, horário, DNS ou capacidade de executar testes não completou a transição operacional.

A suíte pode verificar assinatura, identidade, rede, ligação ao controlador, relógio, DNS, ping, traceroute e funções tocadas pelo lançamento. Alvos e limiares sensíveis podem continuar protegidos. O registro público precisa apenas da versão da suíte, da regra e do resultado agregado.

O rollback também deve ser um estado com causa, autoridade e escopo. É preciso saber qual limiar o acionou, que coorte parou e se as medições do intervalo precisam de anotação. Reverter com disciplina não é derrota; é parte do desenho seguro.

Um manifesto gerado pela operação

O RIPE Atlas já publica o índice de firmware, notas detalhadas e o lançamento 5130 no GitHub. O repositório mostra branches, perfis e classes de chaves; as sondas mostram a versão. Falta a junção persistente entre esses registros.

Ela deve nascer automaticamente nos sistemas de build e implantação, não de um relatório manual. Em atualização urgente, pode começar com versão, commit, hash, classe de assinatura e autoridade, recebendo os resultados de coorte numa janela definida.

As fontes públicas não demonstram ausência de SBOM, atestado de build, log de assinatura ou livro de implantação dentro do RIPE NCC. A recomendação é mais limitada: a afirmação pública sobre a versão deve carregar identificadores suficientes para ser reconstruída por quem interpreta as medições.

Uma base comum reduz trabalho e pode espalhar uma mesma correção com mais rapidez. Também pode ampliar o alcance de um erro compartilhado. A resposta não é manter fragmentação, e sim preservar uma memória proporcional ao alcance da automação.

Fontes