diff --git a/content/links/mitigating-memory-safety-issues-in-oss.md b/content/links/mitigating-memory-safety-issues-in-oss.md new file mode 100644 index 0000000..0b26c90 --- /dev/null +++ b/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). + + + +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. diff --git a/content/links/mitigating-memory-safety-issues-in-oss.pt.md b/content/links/mitigating-memory-safety-issues-in-oss.pt.md new file mode 100644 index 0000000..5668c18 --- /dev/null +++ b/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). + + + +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." + + +