Taverna /dev/All

O que ocorre quando o mantenedor de um grande projeto open source vai pro saco?

#1

image

Recentemente o responsável pelo projeto core-js foi encarcerado por ter matado uma pessoa em um acidente de moto. Era o único mantenedor do projeto, que agora não está mais recebendo updates e não tem uma equipe responsável por mantê-lo neste período de encarceramento do seu mantenedor.

Pouca gente se lembra mas anos atrás tivemos um problema similar com o sistema de arquivos (!!!) ReiserFS. Seu criador e principal mantenedor, Hans Reiser, também foi preso por que ASSASSINOU sua esposa a sangue frio. E isto na época em que este era um dos sistemas de arquivos mais populares do Linux.

O site The Register publicou uma matéria muito interessante a respeito (curiosamente não mencionam o caso do Hans Reiser) que vale muito à pena ler.
Segue o link: https://www.theregister.co.uk/2020/03/26/corejs_maintainer_jailed_code_release/

E aí? O que acham deste fator risco no open source?
Isto é especialmente importante no caso do JavaScript que tem inúmeros projetos assim no NPM.

#2

Eu lembro do Reiser. Além de ser uma morte, foi uma morte bem violenta, chocou todo mundo dessa nossa bolha.

Penso que, em primeiro lugar, ter uma boa licença. Sou adepto das mais permissivas, ao estilo BSD. De chabu, forka o projeto e boa.

Mas pensando de uma forma global, esse é um tema que tem me atormentado desde que fui engolido por um projeto Python2 com um montão de dependências antigas. A relação com o tema aqui é que eu gostaria de um serviço em que eu pudesse, primeiro, ter cada dependência desse grafo maldito auditada e, segundo, ter patches de segurança, mas não manualmente.

Cada pepino desses, sendo classificado, talvez, por uma nota de segurança, levando em conta, comunidade, desenvolvedores, fundações, código bem escrito e auditado, e muitas outras coisas que possam dar uma nota a cada elo, gerando uma nota final.

Simplesmente dar um npm install ou um pip install, está cada vez mais impraticável.

Eu já vi algumas iniciativas há algum tempo, nesse sentido, de ter repositórios mais seguros, consequentemente, sem aquelas versões tão atualizadas, mas penso que vale muito a troca.

É um projeto que preciso sair da procrastinação e testar.

#3

por isso é bom ter como boa prática evitar projeto de uma pessoa.
outro caso, go usar o github ou qqr outro sistema de git como repo das dependências, por isso vai ver mto projeto com o vendor “comitado” no repo p/ não correr o risco de um novo left-pad.js.

1 Curtida
#4

GO tem uma, ou mais, iniciativa de uma fonte segura para instalação de dependências para garantir que o repo não suma da noite pro dia, mas não me lembro o nome do projeto.

Penso que o problema é quando você começa a usar coisas gigantescas que usam outras que nem imaginamos que estejam lá.

Aí fica osso :slight_smile: Mas tomar os cuidados que você indicou já é uma excelente prática.

itexto