3.7 KiB
+++ title = "O problema de go não é a vulnerabilidade do XML" date = 2020-12-15
[taxonomies] tags = ["go", "golang", "padrões", "xml", "vulnerabilidade"] +++
Ontem eu postei alguns comentários sobre a vulnerabilidade da biblioteca XML do go e algumas pessoas disseram que isso não era grande coisa.
O problema não é a vulnerabilidade em si, no entanto.
Ainda, o problema é só parcialmente com relação ao fato que a vulnerabilidade
não pode ser corrigida de forma confiável. E não é em relação à biblioteca
"http" que tinha um problema de negação-de-serviço. E não é em relação à
biblioteca de números naturais (e mais especificamente divRecursiveStep) que
causou um erro na rede de Etherium. E não é em relação que a biblioteca "ssh"
tinha uma vulnerabilidade que foi corrigida.
O problema é o padrão.
Eu não espero que as coisas tenham aquele toque místico de "tudo tem que ser perfeito". Poxa, com a exceção do problema da biblioteca "xml", todos os outros problemas já foram corrigidos.
Mas existe um padrão surgindo na biblioteca padrão do go que mostra quão pouco
cuidado foi tomado na sua construção. E, junto com esse padrão, tem o
problema que isso está na biblioteca padrão. Bibliotecas padrão deveriam, além
de prover uma infra-estrutura para aplicações maiores, serem implementações de
referencia. Por exemplo, se você quiser saber como é que diabos o Python fez
para adicionar suporte ao SQLite, basta você olhar a biblioteca padrão (FFI);
ou se você se perguntar como é que sets em Python são tão rápidos (tão rápidos
com relação ao resto das coisas em Python, quero dizer), você também
pode consultar a biblioteca padrão (sets são escritos em C); ou como é que eles
fizeram para que "namedtuples" criassem objetos magicamente (eval). Essas
partes descrevem como você deve construir algo que conecte com algo externo,
que seja rápido ou que seja mágico.
E esse padrão mostra que a biblioteca padrão do go está fazendo as coisas de forma errada. Parece que o time de go focou muito em "adicionar valor" e muito pouco em "servir de referência".
Outra indicação que tem algo errado com a linguagem: em quatro meses, o problema da ordenação não pode ser corrigido. Em metade desse tempo eu consigo escrever bindings da libxml2 em Python, ou até mesmo em Rust, mesmo não tendo experiência alguma com o FFI de Python ou Rust. Isso significa que essa camada que dá acesso a biblioteca padrão à coisas externas está tendo muito controle, de forma que estruturas externas não podem ser usadas sem que sejam bagunçadas pelo runtime. Se o FFI tivesse liberdade suficiente para expor somente a camada mais externa, escrever uma implementação de parser XML em C e só expor as camadas superiores seria completamente viável em quatro meses -- mesmo sem usar a libxml2.
Todos esses padrão mostram que tem algo de errado com a arquitetura da linguagem. E é por isso que eu disse que qualquer coisa no mínimo semi-séria não deveria ser escrita em go.
Eu sou uma pessoa que diz coisas controversas de tempo em tempos. No começo desse ano eu disse, em um evento, que um líder técnico que valesse o seu próprio salário não recomendaria go para coisa alguma. E eu mantenho essa posição. Líderes técnicos devem ver esse tipo de problema aparecer e tomar ações para evitar que o projeto caia num buraco que seja complicado de sair depois. E esse padrão de problemas com go já tem aparecido a muito tempo.
PS: Vocês devem ter notado que eu digitei "go" e não "Go" na maior parte desse post. Isso é proposital; eu não acredito que a linguagem mereça ser chamada com um "G" maiúsculo.