Uma discussão está ocorrendo entre os defensores do software livre e do código aberto que merece uma reflexão mais séria. Não se discute a importância e alcance das coisas surpreendentes que podem ser feitas pelo código aberto, produzindo um ótimo software. Muitos desenvolvedores colocam seus egos de lado para criar ótimos programas com a ajuda de outros. Agora, no entanto, um grupo de programadores está colocando suas próprias preocupações à frente do bem coletivo e potencialmente destruindo o software de código aberto para todos.
Por exemplo, o mantenedor do gerenciador de pacotes do 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 lançar uma mensagem de paz para os desktops. Até então, parecia inofensivo.
Porém, descobriu-se que Miller 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 programa node-ipc o que provocou um verdadeiro caos instantâneo! Inúmeros servidores e PCs foram desativados enquanto eram atualizados para o código mais recente e, em seguida, seus sistemas tiveram suas unidades apagadas.
Miller sustentou em sua defesa que “Tudo isso é público, documentado, licenciado e de código aberto“. Porém, esse argumento não se sustenta.
Desenvolvedores estão estragando o software de código aberto?
Liran Tal, o pesquisador da Snyk 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 na participação na comunidade de desenvolvedores? Este mantenedor será confiável novamente para não acompanhar atos futuros em ações tão agressivas ou até mesmo mais agressivas para qualquer projeto em que participe?
Miller não é um excêntrico qualquer. Ele produziu muito código bom, como node-ipc e Node HTTP Server. No entanto, você pode confiar em qualquer código dele para não ser malicioso? Embora ele o descreva como “não malware, [mas] protestware que está totalmente documentado“, outros discordam desta postura.
Como um programador do GitHub escreveu:
O que vai acontecer com isso é que as equipes de segurança das corporações ocidentais que não têm absolutamente nada a ver com a Rússia ou a política vão começar a ver o software livre e de código aberto como um caminho para ataques à cadeia de suprimentos (o que isso é totalmente) 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 apelido nm17 escreveu: “O fator de confiança do código aberto , que era 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 explorado para fazer/dizer o que algum desenvolvedor aleatório na internet achou que ‘era a coisa certa a fazer’.”
Ambos levantam 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 intenção de Miller pode parecer legal, 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?
Confiança é a chave do negócio
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, mantenedor do kernel Linux para o ramo estável, disse quando estudantes da Universidade de Minnesota deliberadamente tentaram inserir código incorreto no kernel 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, a Exception General Public License (eGPL) de 2009, uma revisão da GPLv2, tentou proibir “exceções”, como usuários militares e fornecedores, de usar seu código. Falhou. Outras licenças, como a licença JSON, com sua cláusula ingênua “o software deve ser usado para o bem, não para o mal” ainda existe, 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, sua licença Hipocrática adicionou à licença de código aberto do MIT uma cláusula afirmando:
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.
Notícias Relacionadas
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 nas Quatro Liberdades Essenciais da Free Software Foundation (FSF). 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:
A 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. dar permissão apenas para bons usos, ou proibir os maus 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, chefe de pesquisa da empresa de segurança Nextron Systems, que considerou “desativar minhas ferramentas gratuitas em sistemas com determinadas configurações de idioma e fuso horário”, finalmente decidiu não fazer isso. Por quê? Porque, ao fazê-lo, “desabilitaríamos também as ferramentas dos sistemas de críticos e livres-pensadores que condenam as ações de seus governos”.
Atos vêm se repetindo
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 deliberadamente sabotou 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 falharam.
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 ser feito. 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 por um salário melhor não funcionou tão bem para ele.
Diversão e lucro
E há pessoas que deliberadamente colocam malware em seu código aberto por diversão e lucro. Por exemplo, a empresa de segurança DevOps JFrog 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 na plataforma de comunicação e distribuição digital do Discord.
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.
De forma mais prática, devemos começar a adotar o uso do Software Package Data Exchange (SPDX) e do Software Bill of Materials (SBOM) da Linux Foundation. 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 o código em vez de confiar cegamente nele. É a única coisa inteligente a fazer daqui para frente.
Via ZDNet
