Browse Source

Go and the XML problem

master
Julio Biason 4 years ago
parent
commit
0f8c6f6fb9
  1. 73
      content/thoughts/go-problem-is-not-the-xml-vulnerability.md
  2. 75
      content/thoughts/go-problem-is-not-the-xml-vulnerability.pt.md

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

@ -0,0 +1,73 @@
+++
title = "Go problem is not the XML vulnerability"
date = 2020-12-15
[taxonomies]
tags = ["go", "golang", "thoughts", "stdlib", "patterns"]
+++
Yesterday I posted [some comments about the vulnerability in go XML
stdlib](@/links/go-xml-vulnerability.md)[^1] and some people said it was not a big
deal.
The problem is not the vulnerability in itself, though.
<!-- more -->
Also, the problem is just partially related the fact that it can't be reliable
fixed. And it is not related with the "http" library had a DoS problem. And it
is not related with the natural number functions (and specifically
`divRecursiveStep`) had an error that put Etherium network down. And it is not
related with the "ssh" library had a vulnerability that had to be fixed.
The problem is the pattern.
I'm don't expect projects to be some mythical "everything should be flawless".
Heck, with the exception of the "xml" issue in the original post, all other
issues are already fixed.
But there is a pattern emerging from go stdlib that shows that little care was
taken when building it. And, along with this pattern, we have the issue that
this is in the stdlib. Stdlibs should, even more than just provide an
infrastructure for bigger applications, be reference implementations. For
example, if you want to see how the heck Python managed to add SQLite, you just
need to check Python stdlib (FFI); you can check the source (FFI); or if you
want to know how can sets in Python be fast (faster then everything else in
Python, that is) you can also check the stdlib (it is written in C); or how they
managed to make "namedtuples" create objects dynamically (`eval`). All those
describe how you can build something that connects to something external, that
is fast or that is magical.
And the pattern shows that go stdlib is doing it wrong. It seems the go team
focused too much in "adding value" and too little in "being a reference".
Another example that there is something wrong with the language: in four
months, the problem with the ordering could not be fixed. In half of that time,
I can write binding for libxml2 in Python, or even Rust, even if I'm not that
experienced with Python or Rust FFI. That means that the layer that gives the
stdlib access to external things is taking too much control, in a way that you
can't let external libraries use their own structures without that being messed
up with the runtime. If the FFI had enough freedom to just expose the top
layers, writing their own implementation of a XML parser in C and just exposing
to the top layers would be completely doable in four months -- even without the
use of libxml2.
All those are patterns of things going wrong with the language architecture.
And that's why I said that anything half-serious shouldn't be written in go in
the first place.
I'm someone that likes to say something controversial from time to time. At the
start of this year, in one event, I said that any technical leader worth its
salt wouldn't recommend go for anything. And I stand by that. Tech leaders
should see this kind of problem appear and take steps to not be dragging into
some hole they can't get out, and the pattern of architectural problems with go
was emerging a long time already.
PS: You may have noticed that I typed "go" instead of "Go" in most of this
post. This is on purpose; I don't believe the language deserves getting a
capital "G".
---
[^1]: From now on, I'll use "stdlib" for "standard libraries", the
libraries/modules that come with a language.

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

@ -0,0 +1,75 @@
+++
title = "O problema de go não é a vulnerabilidade"
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:
-->
Loading…
Cancel
Save