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