Julio Biason
4 years ago
2 changed files with 148 additions and 0 deletions
@ -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. |
@ -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…
Reference in new issue