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