Alguns desenvolvedores estão estragando o software de código aberto

Uma das coisas mais surpreendentes sobre o código aberto não é que ele produz um ótimo software. É que tantos desenvolvedores colocam seus egos de lado para criar ótimos programas com a ajuda de outros. Agora, no entanto, um punhado de programadores está colocando suas próprias preocupações à frente do bem de muitos e potencialmente destruindo o software de código aberto para todos.

Por exemplo, o mantenedor do gerenciador de pacotes JavaScript RIAEvangelist, Brandon Nozaki Miller, escreveu e publicou um pacote de código-fonte npm de código aberto chamado peacenotwar. Ele fez pouco além de imprimir uma mensagem de paz para os desktops. Até agora, tão inofensivo. 

Miller então inseriu um código malicioso no pacote para sobrescrever os sistemas de arquivos dos usuários se o computador deles tivesse um endereço IP da Rússia ou da Bielorrússia. Ele então o adicionou como uma dependência ao seu popular nó-ipc programa e caos instantâneo! Vários servidores e PCs ficaram inativos enquanto atualizavam para o código mais recente e, em seguida, seus sistemas tinham suas unidades apagadas. 

A defesa de Miller, “Tudo isso é público, documentado, licenciado e de código aberto”, não se sustenta. 

Liran Tal, o Snyk O pesquisador que descobriu o problema disse: “Mesmo que o ato deliberado e perigoso [seja] percebido por alguns como um ato legítimo de protesto, como isso reflete na reputação futura do mantenedor e participação na comunidade de desenvolvedores? Esse mantenedor seria confiável novamente para não acompanhar atos futuros em ações tão agressivas ou ainda mais agressivas para qualquer projeto em que participe?” 

Miller não é um excêntrico aleatório. Ele produziu muito código bom, como node-ipc, e Servidor HTTP do nó. Mas, você pode confiar em qualquer código dele para não ser malicioso? Enquanto ele descreve como “não malware, [mas] protestware que está totalmente documentado”, outros discordam venenosamente. 

Como um programador do GitHub escreveu: “O que vai acontecer com isso é que as equipes de segurança em corporações ocidentais que não têm absolutamente nada a ver com a Rússia ou política vão começar a ver software livre e de código aberto como uma avenida para ataques à cadeia de suprimentos (o que é totalmente isso) e simplesmente começar a banir software livre e de código aberto – todo software livre e de código aberto – dentro de suas empresas.” 

Como outro desenvolvedor do GitHub com o identificador nm17 escreveu: “O fator de confiança de código aberto, que foi baseado na boa vontade dos desenvolvedores agora praticamente se foi, e agora, mais e mais pessoas estão percebendo que um dia, sua biblioteca/aplicativo pode ser explorada para fazer/dizer o que algum desenvolvedor aleatório na internet pensou ' foi a coisa certa a fazer.'”

Ambos fazem pontos válidos. Quando você não pode usar o código-fonte a menos que concorde com a posição política de seu criador, como pode usá-lo com confiança? 

O coração de Miller pode estar no lugar certo - Slava Ukraini! — mas o software de código aberto infectado com uma carga maliciosa é o caminho certo para proteger a invasão da Ucrânia pela Rússia? Não, não é. 

O método de código aberto só funciona porque confiamos uns nos outros. Quando essa confiança é quebrada, não importa a causa, a estrutura fundamental do código aberto é quebrada. Como Greg Kroah-Hartman, o mantenedor do kernel do Linux para o ramo estável, disse quando estudantes da Universidade de Minnesota deliberadamente tentaram inserir código ruim no kernel do Linux para um experimento em 2021, disse: “O que eles estão fazendo é comportamento malicioso intencional e não é aceitável e totalmente antiético.”

As pessoas há muito argumentam que o código aberto também deve incluir disposições éticas. Por exemplo, em 2009 Licença Pública Geral de Exceção (eGPL), uma revisão do GPLv2, tentou proibir “exceções”, como usuários e fornecedores militares, de usar seu código. Falhou. Outras licenças, como a Licença JSON com sua docemente ingênua cláusula “o software deve ser usado para o bem, não para o mal” ainda por aí, mas ninguém a impõe.  

Mais recentemente, a ativista e desenvolvedora de software Coraline Ada Ehmke introduziu uma licença de código aberto que exige que seus usuários ajam moralmente. Especificamente, ela Licença Hipocrática adicionado ao Licença de código aberto do MIT uma cláusula dizendo: 

“O software não pode ser usado por indivíduos, corporações, governos ou outros grupos para sistemas ou atividades que ativamente e conscientemente ponham em perigo, prejudiquem ou ameacem o bem-estar físico, mental, econômico ou geral de indivíduos ou grupos desprivilegiados em violação da Declaração Universal dos Direitos Humanos das Nações Unidas”.

Parece bom, mas não é de código aberto. Veja bem, o código aberto é por si só uma posição ética. Sua ética está contida no Fundação do Software Livre (FSF)'s Quatro Liberdades Essenciais. Esta é a base para todas as licenças de código aberto e sua filosofia central. Como o especialista jurídico de código aberto e professor de direito da Columbia, Eben Moglen, disse na época que licenças éticas não podem ser software livre ou licenças de código aberto: 

"Liberdade zero, o direito de executar o programa para qualquer finalidade, vem em primeiro lugar nas quatro liberdades, porque se os usuários não têm esse direito em relação aos programas de computador que executam, eles não têm nenhum direito sobre esses programas. Esforços para dar permissão apenas para bons usos, ou para proibir maus usos aos olhos do licenciante, violam o requisito de proteção da liberdade zero”. 

Em outras palavras, se você não puder compartilhar seu código por qualquer motivo, seu código não é verdadeiramente de código aberto. 

Outro argumento mais pragmático sobre proibir um grupo de usar software de código aberto é que bloquear algo como um endereço IP é um pincel muito amplo. Como Florian Roth, empresa de segurança Sistemas Nextron' Chefe de Pesquisa, que considerou “desabilitando minhas ferramentas gratuitas em sistemas com certas configurações de idioma e fuso horário”, finalmente decidiu não fazer isso. Por quê? Porque ao fazê-lo, “também desabilitaríamos as ferramentas em sistemas de críticos e livres-pensadores que condenam as ações de seus governos”. 

Infelizmente, não são apenas as pessoas que tentam usar o código aberto para o que consideram um propósito ético mais elevado que está causando problemas para o software de código aberto. 

No início deste ano, o desenvolvedor JavaScript Marak Squires sabotou deliberadamente suas obscuras, mas de vital importância, bibliotecas Javascript de código aberto 'colors.js' e 'faker.js'. O resultado? Dezenas de milhares de programas JavaScript explodiram.

Por quê? Ainda não está totalmente claro, mas em uma postagem do GitHub excluída desde então, Squires escreveu: “Respeitosamente, Não vou mais apoiar Fortune 500s (e outras empresas de menor porte) com meu trabalho gratuito. Não há muito mais a dizer. Aproveite isso como uma oportunidade para me enviar um contrato anual de seis dígitos ou dividir o projeto e ter outra pessoa trabalhando nele.” Como você pode imaginar, essa tentativa de chantagear seu caminho para um salário não funcionou tão bem para ele. 

E há pessoas que deliberadamente colocam malware em seu código-fonte aberto por diversão e lucro. Por exemplo, a empresa de segurança DevOps JFrogName descobriu 17 novos pacotes maliciosos JavaScript no repositório NPM que deliberadamente atacam e roubam os tokens Discord de um usuário. Estes podem então ser usados ​​no Discord comunicações e plataforma de distribuição digital.

Além de criar novos programas maliciosos de código aberto que parecem inocentes e úteis, outros invasores estão pegando softwares antigos e abandonados e os reescrevendo para incluir backdoors que roubam criptomoedas. Um desses programas foi o event-stream. Ele tinha um código malicioso inserido nele para roubar carteiras de bitcoin e transferir seus saldos para um servidor de Kuala Lumpur. Houve vários episódios semelhantes ao longo dos anos.

Com cada movimento, a fé no software de código aberto é desgastada. Como o código aberto é absolutamente vital para o mundo moderno, essa é uma tendência ruim. 

O que podemos fazer sobre isso? Bem, por um lado, devemos considerar com muito cuidado quando, se alguma vez, devemos bloquear o uso de código-fonte aberto. 

Mais praticamente, devemos começar a adotar o uso de Fundação Linux Troca de dados do pacote de software (SPDX) e Lista de materiais de software (SBOM). Juntos, eles nos dirão exatamente qual código estamos usando em nossos programas e de onde ele vem. Então, seremos muito mais capazes de tomar decisões informadas.

Hoje, com frequência, as pessoas usam código-fonte aberto sem saber exatamente o que estão executando ou verificando se há problemas. Eles assumem que está tudo bem com isso. Isso nunca foi uma suposição inteligente. Hoje, é uma tolice absoluta. 

Mesmo com todas essas mudanças recentes, o código aberto ainda é melhor e mais seguro do que as alternativas de software proprietário da caixa preta. Mas, devemos verificar e verificar o código em vez de confiar cegamente nele. É a única coisa inteligente a fazer daqui para frente.

Histórias relacionadas: