Commented Link: Mitigating Memory Safety Issues in OSS

content/links/mitigating-memory-safety-issues-in-oss.md

@@ -0,0 +1,64 @@
++++
+title = "Commented Link:  Mitigating Memory Safety Issues in Open Source Software"
+date = 2021-02-18
+
+[taxonomies]
+tags = ["links", "google", "safety", "rust"]
++++
+
+Initially announced on HackerNews as "Google to Pay Developers to Port Their Code
+to Rust" [on this
+post](https://security.googleblog.com/2021/02/mitigating-memory-safety-issues-in-open.html),
+what is actually going on is not quite what it seems.
+
+And it seems this time HackerNews comments [actually got what it actually
+means](https://news.ycombinator.com/item?id=26179032).
+
+<!-- more -->
+
+But let me surmise this.
+
+First of all, the funding is not going to open source developers so they can
+secure their applications, or look for alternatives that seem more
+secure. Google will fund another company -- ISRG -- for them to write new
+versions of some code. So, even if the idea is pretty good, it won't translate
+into offering help to the authors so they could still work on their project; the
+money will all go to someone else, to provide patches.
+
+This "someone will provide patches" always remind me of a talk by Brett Cannon
+on a DjangoCon. "You see this little puppy, so cute, but what I see is 10 years
+of walks, giving food and picking its crap."[^1] So, while ISRG will provide
+patches for improving open source projects using memory safe languages, there is
+no word about "and continue to make things work". Sure it is nice to have a
+safety patch in some other language landing in your project, but who will take
+care of it in the next version? And the next one? ISRG or the original author --
+whose, again, got absolutely nothing in the first place?
+
+Second, there is this line:
+
+> The ISRG's approach of working directly with maintainers to support rewriting
+> tools and libraries incrementally falls directly in line with our perspective
+> here at Google.
+
+What feels strange about it is that we know, for a long time, that Google does
+not work for the common good; it works for itself (and that's ok for the
+company). But what if the secure way of some project does not fall in the exact
+"perspective" of Google? Will they fork it? Accept that their perspective isn't
+the right way?
+
+For example, recently Cryptography replaced a core element to use Rust -- which
+totally makes sense in a secure project. The problem is that some people, using
+some non-mainstream architectures, [saw their builds
+failing](https://github.com/pyca/cryptography/issues/5771). Now, again, it makes
+sense for something that enforces security to use a memory safe language, but
+what that was the proposed solution by ISRG -- which, again, aligns with the
+perspective of Google -- and the author decided that portability is more
+important?
+
+In the end, it feels like Goog is trying another way to take hold on open source
+projects for their own purposes and not actually caring about helping end users
+to have a better internet experience.
+
+---
+
+[^1]: Paraphrased, I can't really recall the actual quote.

content/links/mitigating-memory-safety-issues-in-oss.pt.md

@@ -0,0 +1,74 @@
++++
+title = "Link Comentado: Mitigando Problemas de Segurança de Memória em Softwares Open Source"
+date = 2021-02-18
+
+[taxonomies]
+tags = ["links", "google", "segurança", "rust"]
++++
+
+Inicialmente anunciado no HackerNews como "Google Vai Pagar Desenvolvedores
+Para Portarem Seu Código Para Rust" [nesse
+post](https://security.googleblog.com/2021/02/mitigating-memory-safety-issues-in-open.html),
+mas o conteúdo não parece ser exatamente o que é dito.
+
+E parece que dessa vez os comentários do HackerNews [entenderam o que o post
+realmente quer dizer](https://news.ycombinator.com/item?id=26179032).
+
+<!-- more -->
+
+Mas me deixem fazer um resumo.
+
+Primeiro, o dinheiro não irá para os desenvolvedores dos projetos open source
+para que estes possam garantir a segurança dos seus projetos, ou olhar para
+alternativas que tornem os projetos mais seguros. Google irá dar o dinheiro para
+outra empresa -- ISRG -- para que eles escrevam novas versões de alguns
+códigos. Assim, embora a ideia pareça ser boa, isso não quer dizer que eles
+estarão oferecendo dinheiro para os autores trabalharem nos seus projetos; o
+dinheiro irá para outra pessoa, que irá prover os patches.
+
+Esse "alguém vai prover os patches" me lembra de uma talk do Brett Cannon em uma
+DjangoCon. "Você vê esse cachorrinho, tão bonitinho, mas o que eu vejo são 10
+anos de caminhadas, dar comida e juntar coco."[^1] Assim, embora a ISRG mande
+patches para melhorar projetos open source usando linguagens com proteção de
+memória, não existe qualquer menção a "e continuar a fazer funcionar". Claro que
+é legal ter um patch de segurança em outra linguagem no seu projeto, mas quem é
+que vai continuar cuidando dela pra próxima versão? E na próxima? ISRG ou o
+autor original -- que, de novo, não recebeu absolutamente nada para isso?
+
+Segundo, há essa linha[^2]:
+
+> A forma que a ISRG trabalha diretamente com os mantenedores para suportar a
+> reescrita de ferramentas e bibliotecas incrementalmente encaixa perfeitamente
+> com a nossa perspectiva aqui na Google.
+
+O que parece estranho aqui é que nós sabemos, por um bom tempo, que Google não
+trabalha para o bem comum; ela trabalha pra si mesma (e é ok para uma
+empresa). Mas e se a forma segura de algum projeto não encaixar com a
+"perspectiva" esperada pelo Google? Eles vão fazer um fork? Aceitar que a
+perspectiva deles não é a forma correta?
+
+Por exemplo, recentemente a biblioteca Cryptography trocou um componente base
+para usar Rust -- o que faz todo o sentido num projeto de segurança. O problema
+é para algumas pessoas, usando arquiteturas não comuns, [viu seus builds
+quebrando](https://github.com/pyca/cryptography/issues/5771). De novo, faz
+sentido que algo que é usado para segurança use uma linguagem com proteção de
+memória, mas o que aconteceria se a solução proposta pela ISRG -- que, de novo,
+se encaixa na perspectiva do Google -- e o autor decidir que portabilidade é
+mais importante?
+
+No final, parece que o Goog está tentando mais uma vez tomar controle de
+projetos open source para seus propósitos e não realmente se preocupando para
+que usuários finais tenha uma melhor experiência na internet.
+
+---
+
+[^1]: Parafraseando, eu não me lembro exatamente das palavras usadas.
+
+[^2]: Traduzido por mim, o texto original diz: "The ISRG's approach of working
+  directly with maintainers to support rewriting tools and libraries
+  incrementally falls directly in line with our perspective here at Google."
+
+
+<!-- 
+vim:spelllang=pt:
+-->