blog/content/thoughts/go-problem-is-not-the-xml-vulnerability.pt.md

+++
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](@/links/go-xml-vulnerability.pt.md) e algumas pessoas disseram que isso
não era grande coisa.

O problema não é a vulnerabilidade em si, no entanto.

<!-- more -->

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.

<!-- 
vim:spelllang=pt:
-->