Contexto
report_signing.py assina o relatório com HMAC-SHA256 usando uma chave embutida no código:
HMAC_KEY = b"telador-br-v3.2-tamper-evident-2026"
O próprio docstring é honesto: "pra repos open-source isso é tamper-EVIDENT … mas não tamper-PROOF". O ponto desta issue é o descompasso entre essa realidade e como o produto comunica ("relatório assinado, auditável" no site e no README).
Por que importa no modelo de ameaça do Telador
Aqui o suspeito é o adversário, e o cenário exato que preocupa é "o suspeito edita o relatório pra parecer limpo". Como a chave é pública (repo open-source), qualquer um faz:
import report_signing
forjado = relatorio_editado
hmac_valido = report_signing.compute_hmac(forjado) # passa no verify_hmac
…e gera um HMAC válido pra um relatório falsificado. Ou seja, contra um adversário motivado o HMAC do relatório oferece zero autenticidade — protege só contra alteração acidental/casual.
A parte que de fato ajuda é o SHA256 do .exe comparado com a release do GitHub (isso o suspeito não recompila facilmente sem perceberem). O HMAC do relatório, não.
Opções
- Rebaixar a linguagem (mais barato): trocar "assinado" por "verificação de integridade (anti-alteração acidental)" no site, README e no banner/relatório. Deixa claro que não é prova contra adulteração intencional.
- Assinatura assimétrica de verdade: chave privada fora do binário (ex.: assinar no servidor de release, ou Ed25519 com a privada só no maintainer) e verificação com a pública embutida. Aí vira tamper-proof de verdade, mas muda o fluxo (relatório 100% local não consegue assinar com chave que não está na máquina).
- Manter como está, mas documentar explicitamente a limitação no README/SECURITY.md pra não dar falsa confiança ao supervisor.
Sem ação de código urgente — é decisão de design/produto. Abrindo pra registrar.
Contexto
report_signing.pyassina o relatório com HMAC-SHA256 usando uma chave embutida no código:O próprio docstring é honesto: "pra repos open-source isso é tamper-EVIDENT … mas não tamper-PROOF". O ponto desta issue é o descompasso entre essa realidade e como o produto comunica ("relatório assinado, auditável" no site e no README).
Por que importa no modelo de ameaça do Telador
Aqui o suspeito é o adversário, e o cenário exato que preocupa é "o suspeito edita o relatório pra parecer limpo". Como a chave é pública (repo open-source), qualquer um faz:
…e gera um HMAC válido pra um relatório falsificado. Ou seja, contra um adversário motivado o HMAC do relatório oferece zero autenticidade — protege só contra alteração acidental/casual.
A parte que de fato ajuda é o SHA256 do
.execomparado com a release do GitHub (isso o suspeito não recompila facilmente sem perceberem). O HMAC do relatório, não.Opções
Sem ação de código urgente — é decisão de design/produto. Abrindo pra registrar.