Às vésperas da eleição, vi um carrossel do perfil coisa_de_dev sobre o Uenux, o sistema operacional que roda dentro da urna eletrônica. Eu sabia vagamente que a urna "usava Linux", mas nunca tinha parado para pensar no que isso significa na prática. Com o primeiro turno marcado para este domingo, 4 de outubro, fui atrás das fontes oficiais do TSE para entender a história direito, do ponto de vista de quem trabalha com Python, Go e PHP e está acostumado a sistemas que vivem conectados.

Três sistemas, um Linux

A urna estreou nas eleições municipais de 1996 e, durante uma década, conviveu com mais de um sistema operacional. Os modelos de 1996, 1998 e 2000 rodavam o VirtuOS, um sistema parecido com o MS-DOS desenvolvido por uma empresa brasileira. O modelo de 2002 veio com o Windows CE 4.0, e os de 2004 e 2006, com o Windows CE 4.2. Como as urnas antigas continuavam em uso ao lado das novas, o TSE mantinha três plataformas na mesma eleição, e cada alteração no programa precisava ser feita pelo menos três vezes. Depois das eleições de 2006, a Seção de Voto Informatizado concluiu que essa manutenção tinha ficado insustentável e decidiu padronizar tudo em Linux: software livre, sem custo de licença e capaz de rodar tanto nas urnas antigas quanto nas que viriam depois.

O que mais me chamou atenção é que a equipe não se limitou a portar o código. Foram 18 meses de trabalho para adaptar o sistema operacional, e os aplicativos eleitorais foram reescritos do zero em vez de apenas adaptados. O Uenux (de Urna Eletrônica com Linux) estreou nas eleições municipais de 2008, e o código usado hoje, escrito em C++, é uma evolução contínua daquele de 2008. Segundo o servidor que liderou a migração, os ganhos apareceram já na primeira eleição: domínio completo de todos os componentes de software pela equipe do TSE, mais agilidade para corrigir e melhorar o sistema e mais estabilidade.

A urna é um sistema embarcado no sentido mais estrito. Hardware e software existem para uma única função, coletar e apurar votos. São só dois cabos, um para a tomada e outro para o terminal do mesário, e não há Wi-Fi, Bluetooth nem qualquer outra forma de entrar em rede; na preparação do Uenux, nenhum software ou hardware de comunicação em rede foi incluído. Em aplicações web, boa parte da segurança existe porque o sistema está exposto à rede. Na urna, não há superfície de ataque remota, e o problema passa a ser outro: garantir que o software lá dentro seja exatamente o que deveria ser.

Só roda o que foi assinado

Cada urna tem um componente físico chamado hardware de segurança, ligado à placa-mãe. Na inicialização, é ele que confere a assinatura digital dos componentes de software à medida que vão sendo carregados, numa cadeia de confiança que começa no hardware. Um programa só roda depois que sua assinatura é conferida, e o TSE afirma que, no dia da eleição, a urna repete essa verificação centenas de vezes. Os arquivos que entram e saem, como o cadastro de eleitores da seção e os dados das candidaturas, também são assinados. Essa arquitetura foi desenhada em 2009, um ano depois da estreia do Uenux. Segundo o tribunal, um mecanismo de verificação de assinatura criado pela equipe para a urna foi disponibilizado publicamente e incorporado ao Linux em 2021.

A outra ponta da cadeia é a Cerimônia de Assinatura Digital e Lacração. Neste ano, a compilação dos programas aconteceu de 1º a 3 de setembro, acompanhada por entidades fiscalizadoras, e no dia 4 o TSE e essas entidades assinaram digitalmente os sistemas. A assinatura gera hashes, uma espécie de impressão digital de cada programa, e as mídias foram lacradas e guardadas numa sala-cofre. Depois disso, qualquer mudança exigiria nova análise, compilação, assinatura e lacração. É o hardware de segurança que garante, segundo o TSE, que o software auditado na cerimônia seja o mesmo que vai rodar em qualquer uma das 563.910 urnas aptas para 2026.

Antes da lacração, o código-fonte fica disponível para inspeção. Para estas eleições, o acesso foi aberto em 2 de outubro de 2025 e ficou disponível até a cerimônia. A inspeção é feita pelas entidades fiscalizadoras previstas nas regras do TSE, como partidos, Ministério Público, Polícia Federal e a Sociedade Brasileira de Computação, em ambiente controlado na sede do tribunal, e não num repositório público.

Um detalhe de implementação que achei elegante é o Registro Digital do Voto, usado desde 2004. Em vez de gravar os votos na ordem em que chegam, o arquivo os mantém ordenados do menor para o maior número digitado, cargo a cargo. Se três eleitores votam 92, 95 e 90 para prefeito, o RDV guarda 90, 92 e 95, e a sequência de quem votou em quem se perde. É dele que saem a zerésima, impressa antes da votação para mostrar que a urna começa sem nenhum voto, e o Boletim de Urna, impresso no encerramento, afixado na porta da seção e publicado no Portal de Dados Abertos do TSE.

Hoje, véspera do primeiro turno, os tribunais regionais escolhem ou sorteiam urnas que passarão por auditoria durante a votação. Só em São Paulo, são 43 equipamentos.

Testar, corrigir, testar de novo

A parte que mais conversa com a minha rotina é o Teste Público de Segurança, realizado desde 2009. Investigadores de fora da Justiça Eleitoral apresentam planos de ataque, que passam pela avaliação de uma comissão, e os aprovados são executados num laboratório montado no TSE. A 8ª edição teve recorde de 149 inscritos e, de 1º a 5 de dezembro de 2025, 29 planos foram executados. Uma pequena parte gerou achados, que os relatórios oficiais classificaram como incapazes de comprometer o sigilo do voto ou o resultado. Os pontos foram corrigidos e, de 13 a 15 de maio de 2026, os próprios investigadores voltaram para o Teste de Confirmação.

Esse teste é só uma etapa de um ciclo de dois anos que começa logo depois de cada eleição: avaliação do que funcionou, evolução do software, teste público, nova rodada de melhorias, validação com os tribunais regionais e, por fim, a lacração. Quando a apuração termina, o próximo ciclo já está começando.

O que eu levo disso

Não escrevi este texto para dizer que a urna é perfeita, nem o contrário. Segurança é processo, e o teste público existe justamente porque sempre há algo a melhorar. O que me prendeu foi a engenharia. Padronizar uma plataforma, mesmo pagando o preço de reescrever tudo, simplificou o trabalho de um jeito que nenhum remendo resolveria. E reduzir o sistema ao essencial, sem rede e sem nada que não seja necessário para votar, acabou sendo uma decisão de segurança tão importante quanto qualquer algoritmo de criptografia.

Para mim, a principal lição é que confiança, em software, se constrói com um processo que outras pessoas conseguem verificar: código inspecionável, build acompanhado, artefato assinado e um convite aberto para alguém tentar quebrar. Dá para trazer um pouco dessa disciplina para projetos comuns: assinar os artefatos, saber exatamente o que foi para produção e tratar teste de segurança como parte do ciclo, e não como evento isolado. Fica o agradecimento ao @coisa_de_dev pelo post que me fez cair nessa pesquisa.

Fontes