[{"jcr:title":"Como uma brincadeira com código aberto pode mudar a relação com as tecnologias"},{"targetId":"id-share-1","text":"Confira mais em:","tooltipText":"Link copiado com sucesso."},{"jcr:title":"Como uma brincadeira com código aberto pode mudar a relação com as tecnologias","jcr:description":"A mensagem antiguerra usada contra computadores russos deu uma má ideia e pode aumentar a dor de cabeça dos programadores, diz o professor Igor Montagner"},{"subtitle":"A mensagem antiguerra usada contra computadores russos deu uma má ideia e pode aumentar a dor de cabeça dos programadores, diz o professor Igor Montagner","author":"Ernesto Yoshida","title":"Como uma brincadeira com código aberto pode mudar a relação com as tecnologias","content":"A mensagem antiguerra usada contra computadores russos deu uma má ideia e pode aumentar a dor de cabeça dos programadores, diz o professor Igor Montagner   Leandro Steiw   Vulnerabilidades em códigos-fonte de aplicativos de celulares e computadores não são raros. Acontecem com frequência, com maior ou menor risco de segurança, causam uma tremenda dor de cabeça nos usuários, consomem tempo e dinheiro dos programadores e das empresas, mas são contornáveis. Eis que a Rússia invade a Ucrânia, organiza-se um exército informal de TI e inicia-se uma guerra cibernética contra qualquer instituição operante em território russo. Então, alguém decide usar uma atualização de código aberto para enviar mensagens contra a guerra. Funcionou, só que os estilhaços acertaram a comunidade open source . Grande parte dos aplicativos de celulares e de computador do nosso dia a dia tem alguma contribuição da comunidade de código aberto. Em dezembro de 2021, descobriu-se que o Log4J, uma biblioteca na linguagem Java usada para diagnosticar o uso de servidores e aplicativos, apresentava vulnerabilidades e abria brechas para ataques externos. O bug colocou em risco os servidores de Apple, Microsoft, Twitter, Steam, Baidu, Tesla e Oracle, entre outros. Em 2014, o pânico foi instalado por um erro no OpenSSL, o software de criptografia que estabelece a comunicação segura dos sites na internet e expôs meio milhão de servidores da web. Incidentes com pacotes de códigos abertos, como o Log4J e o OpenSSL, já aconteceram por negligência ou interesses comerciais de quem os programou. Segundo [Igor Montagner](https://www.insper.edu.br/pesquisa-e-conhecimento/docentes-pesquisadores/igor-dos-santos-montagner/) , professor do curso de [Ciência da Computação](https://www.insper.edu.br/graduacao/ciencia-da-computacao/) do Insper, as pessoas que cuidavam da manutenção do código não eram capazes de responder rapidamente a esses problemas porque tinham outros trabalhos fixos. Eram voluntários que usavam o tempo livre ou viviam de contribuições minguadas para cuidar de pedaços de softwares que até mesmo as Big Techs replicam para arrecadar fortunas com seus produtos. Em outros casos, o mantenedor quebrou o pacote deliberadamente, alegando que diversas empresas usavam o seu software sem pagar um centavo, apesar do afinco de anos. Em contrapartida, lançou uma versão paga, com uma nova licença de uso, que resolvia o problema que ele mesmo inventou. Houve uma quebra de confiança, mas nenhuma ilegalidade: ele era o dono do pacote. Usava quem quisesse. As versões anteriores continuaram gratuitas, conforme a licença original. O terceiro risco é quando alguém desatina e quebra de propósito os seus códigos ou os de outros programadores. A surpresa vem na forma do protestware adicionado a um dos mais populares códigos abertos usados em redes neurais de inteligência artificial, o node-ipc. Além de exibir a mensagem antiguerra, o ataque deletava arquivos de máquinas localizadas na Rússia e em Belarus. “Problemas com pacotes de softwares são comuns e frequentes. Pode ser apenas um erro, que ainda assim causa problemas. Mas esse da Rússia é diferente. Alguém decidiu que ia tornar a vida dos russos mais difícil”, diz o professor. Quem disparou o alarme foi o Sberbank, simplesmente o maior banco da Rússia. Bacharel e doutor em Ciência da Computação, Montagner diz que o protestware faz parte do chamado ataque à cadeia de suprimentos. Várias linguagens de programação e plataformas adotam a ideia de repositório central de pacotes de códigos. O desenvolvimento de muitos softwares depende desses pacotes. É como se fosse uma AppStore ou Google Play Store, mas para componentes de código. “Esse repositório central de pacotes deveria ser confiável. Se está lá, eu assumo que posso confiar e posso usar”, considera o professor. Ataques à cadeia de suprimentos não são novidade. Uma estratégia habitual é criar um pacote falso com um nome parecido ao original, esperando que algum programador erre na digitação e carregue os códigos com spyware ou outras ameaças. As dependências em softwares nem sempre são diretas. Um primeiro pacote pode depender da instalação de outro que está limpo, mas este segundo depende um terceiro mal-intencionado, que quebra o computador. Inadvertidamente, a malícia pode ser algo como o protesto contra os russos. “Agora, no node-ipc, foi a primeira vez que alguém fez algo malicioso em um pacote tão popular e importante”, observa Montagner. Instalou-se o desconforto. “O abalo do protesto talvez seja menor do que parecia inicialmente, mas o problema é que ele tornou a ideia de protestware mais conhecida. Agora todos sabem que isso é possível. Nada impede que, em algum momento, se criem outras coisas similares”, avalia Montagner. O código era aberto, a modificação estava explícita e qualquer um poderia ver que se apagariam certos arquivos. Bastava verificar quais eram as diferenças da nova versão do código para a anterior. Existem ferramentas que identificam as novidades. “O ponto é que o software depende indiretamente e diretamente de tantas dependências que não se consegue auditar”, afirma. Por isso, a credibilidade das comunidades é tão importante.   Bibliotecas prontas O código-fonte é um conjunto de arquivos de texto escritos em uma ou mais linguagens de programação. A princípio, esse código define o funcionamento de um software por inteiro. Porém, esse formato não é conveniente para distribuição, sendo necessário processá-lo e empacotá-lo em um formato próprio para ser executado pelo computador. Por isso, os programas que instalamos nos nossos computadores e smartphones já chegam empacotados, com tudo pronto para rodar. Código-fonte nunca aparece na vida de um usuário final, pois ele não é necessário para rodar os programas. Já para desenvolvedores, é essencial. Em regra, um desenvolvedor não precisa partir do zero para criar um aplicativo. Existem bibliotecas prontas de componentes que prometem fazer algum trabalho comum a várias aplicações, como ler códigos QR ou emitir boletos, por exemplo. Diversos desses componentes têm seu código-fonte disponível, permitindo que outras pessoas participem de seu desenvolvimento. Montagner lembra que os primórdios da computação foram no contexto acadêmico e científico. As pessoas distribuíam programas como código-fonte para outros rodarem gratuitamente no ambiente de pesquisa e ficava tudo bem. Nesse espaço específico, formado principalmente por universidades, compartilhar as informações desta maneira é costumeiro, quase natural. Quando aparece um interesse mais comercial e os computadores evoluem ao ponto de se conseguir empacotar programas para usuários — e as pessoas comprarem —, surge a ideia de distribuir somente um pacote executável, sem o código-fonte. O criador mantinha a exclusividade sobre o código-fonte. A visão era que o código proprietário seria sempre um tipo de segredo industrial, como a fórmula de um refrigerante ou os direitos autorais de livros, filmes e músicas. Por consequência, editam-se licenças que restringem o uso que o usuário pode fazer do software. Isso gera incômodo em parte da comunidade de desenvolvedores, que decide estabelecer uma nova licença de software que garantisse o uso irrestrito e compartilhado de programas. A General Public License (GPL), criada pelo programador americano Richard Stallman, propõe que todo software “ético” obedeça a quatro regras: todo usuário pode usar sem restrições; o programa pode ser estudado e modificado; as versões modificadas podem ser distribuídas; toda modificação obedece a essas mesmas quatro regras. A esse tipo de software é dado o nome de software livre. Então, o que nasceu livre deve permanecer livre.   Uma regra a menos Posteriormente, o movimento do Código Aberto ( Open Source ) entende que a quarta regra traz uma conotação anticomercial e dificulta o uso de software livre em empresas. O incentivo passa para novas licenças que excluem essa limitação. Modificações podem ser distribuídas sob uma licença paga. O modelo deu certo e se tornou popular na indústria de software. Para Montagner, quando se permite que as pessoas colaborem e construam em cima dessa base de softwares, obtêm-se tanto produtos melhores quanto contribuições que talvez não fossem possíveis se o código não estivesse disponível para todos. Ele explica: “As pessoas hoje falam muito de software de código aberto porque imaginam um modelo de desenvolvimento, de colaboração, no qual todo o processo é público. Assim, eu teria um repositório central de código acessível, e o trabalho da minha equipe, que pode ser paga, seria visto por qualquer um. Isso tem causado pequenos conflitos, porque você perde o controle quando disponibiliza as coisas assim. Parte da ideia original é que você não tivesse controle. Você liberou, aqui estão as regras, agora esse software tem uma vida própria. Quando digo que você pode usar como quiser, estou abdicando de uma dose de poder bem razoável”. Não é porque o desenvolvimento é público e está disponível para qualquer um que as pessoas trabalham de graça. Em geral, todos os projetos grandes, de alcance e de sucesso são feitos por gente que é muito bem paga. São abertos ao público, mas não significa que seja fácil entrar e participar, devido ao forte componente técnico necessário. Mesmo assim, um pedacinho desses projetos pode depender de pacotes de códigos abertos gerenciados por um voluntário. No enrosco do protestware , programas de inteligência artificial dependiam da solução de um programador solitário. “Algumas pessoas trabalham com software de código aberto porque, em algum momento, acharam aquilo interessante. Pode ser um exercício de criatividade ou uma exploração de ideia sem grandes compromissos. Por vezes, isso cresce, aparecem usuários e surge uma dependência desse software por terceiros”, conta Montagner. “Só que era um código avulso postado na internet. Não era uma empresa oferecendo suporte. Código aberto não é um modelo de negócio, mas um código disponível com instruções para quem quiser usar e com a possibilidade de ser melhorado por qualquer um. Existem pessoas que são mantenedoras, que são responsáveis por algum projeto, e não se sentem confortáveis nessa posição pelas mais diversas razões. Para muitos, é uma questão de saúde mental, por exemplo.” Como havia certa confiança de que as pessoas não produziriam algo ruim intencionalmente, essa dependência de grandes projetos a códigos de desconhecidos não incomodava. “Depois do protestware , as empresas podem começar a olhar de viés. Será que alguém vai fazer um novo protesto ou algo do tipo e quebrar meu negócio?”, analisa Montagner. No melhor dos casos, os dados são recuperados, mas perdem-se dias de trabalho e um grande esforço é despendido. A questão envolvendo Log4J, OpenSSL e node-ipc é que componentes de softwares essenciais eram administrados por pessoas que o faziam como voluntárias ou, no caso do node-ipc, por pessoas que se mostraram não confiáveis. Big Techs, instituições financeiras e redes sociais usavam softwares que dependiam de um pacote sem nem contribuir para sua manutenção, nem auditar seu conteúdo.   Alunos colaborativos Software de código aberto está presente no cotidiano dos alunos do Insper, já que boa parte dos pacotes de software e linguagens de programação usadas nos cursos é desenvolvida de maneira colaborativa e aberta. Quem tem vontade de participar de um projeto nesses moldes pode cursar a disciplina eletiva Desenvolvimento Aberto, oferecida para os cursos de [Engenharia de Computação](https://www.insper.edu.br/graduacao/engenharia/engenharia-de-computacao/) e [Ciência da Computação](https://www.insper.edu.br/graduacao/ciencia-da-computacao/) . Exercita-se o modelo de colaboração pública adotado na criação de softwares: como chegar a um projeto desconhecido e encontrar o que fazer, como explorar essa nova base de códigos, onde começar a mexer. Para incentivar as turmas a participar do processo real, o professor também envia contribuições para softwares nas comunidades de código aberto. “Vários alunos tiveram modificações aceitas em softwares que a gente usa durante o curso”, rememora Montagner. Bibliotecas de código aberto como Pandas (análise de dados e visualização) e Pygame (para jogos e aplicações interativas simples) são algumas que têm modificações aceitas de graduandos do Insper. “No fim, eles conseguem experimentar e trabalhar nesse modelo de colaboração”, diz o professor.   Professor Igor Montagner"}]