Browse Source

Commented Link: Mitigating Memory Safety Issues in OSS

master 20210218
Julio Biason 4 years ago
parent
commit
dba57482cc
  1. 64
      content/links/mitigating-memory-safety-issues-in-oss.md
  2. 74
      content/links/mitigating-memory-safety-issues-in-oss.pt.md

64
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.

74
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:
-->
Loading…
Cancel
Save