From 0f8c6f6fb95900727422651ebe3cc00e997f054b Mon Sep 17 00:00:00 2001 From: Julio Biason Date: Tue, 15 Dec 2020 10:21:08 -0300 Subject: [PATCH] Go and the XML problem --- ...go-problem-is-not-the-xml-vulnerability.md | 73 ++++++++++++++++++ ...problem-is-not-the-xml-vulnerability.pt.md | 75 +++++++++++++++++++ 2 files changed, 148 insertions(+) create mode 100644 content/thoughts/go-problem-is-not-the-xml-vulnerability.md create mode 100644 content/thoughts/go-problem-is-not-the-xml-vulnerability.pt.md diff --git a/content/thoughts/go-problem-is-not-the-xml-vulnerability.md b/content/thoughts/go-problem-is-not-the-xml-vulnerability.md new file mode 100644 index 0000000..cde3520 --- /dev/null +++ b/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. + + + +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. diff --git a/content/thoughts/go-problem-is-not-the-xml-vulnerability.pt.md b/content/thoughts/go-problem-is-not-the-xml-vulnerability.pt.md new file mode 100644 index 0000000..403166c --- /dev/null +++ b/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. + + + +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. + +