Um apelo por software enxuto em 2024
(spectrum.ieee.org)- Em uma realidade em que até funções simples mobilizam milhares de dependências e dezenas de milhões de linhas de código, a própria obesidade do software se torna uma grande causa de vulnerabilidades de segurança
- A segurança não depende apenas da densidade de bugs, mas também do volume total de código que um atacante consegue alcançar; uma superfície de ataque desnecessariamente ampla pode levar a comprometimentos reais
- Electron JS, Node.js, imagens Docker e ecossistemas de dependências como npm e PyPI tornam nebulosos o volume e a origem do código distribuído, e até um app para abrir a porta da garagem pode envolver mais de 50 milhões de linhas de código ativo
- Rust, sanitizers e fuzzers melhoram a qualidade do código, mas falhas lógicas de projeto, como executar automaticamente código dentro de documentos, são difíceis de impedir apenas eliminando bugs
- O Trifecta oferece compartilhamento de imagens com 1.600 linhas de código novo, cerca de 5 dependências essenciais e um total de 3 MB, mostrando que é possível criar software moderno com código e dependências limitados
O estado perigoso da segurança de software
- O estado recente da segurança de software é muito ruim
- No último ano, ocorreram incidentes graves de comprometimento em softwares padrão da indústria como Ivanti, MOVEit, Outlook, Confluence, Barracuda Email Security Gateway, Citrix NetScaler ADC e NetScaler Gateway
- Mesmo empresas com muitos recursos, como Apple e Google, cometeram erros de segurança que colocaram clientes em risco
- Por causa da percepção de que software ficou perigoso demais, tornou-se comum o conselho de não executá-lo diretamente e deixá-lo para X as a service ou para a nuvem
- A premissa de que a nuvem torna confiável um software vulnerável também está sendo abalada
- A plataforma de e-mail da Microsoft foi hackeada, incluindo e-mails confidenciais de governos
- Persistem preocupações sobre a segurança da nuvem Azure
- A Okta sofreu seu segundo comprometimento em dois anos, e depois disso houve uma sequência suspeita de casos de invasão envolvendo usuários da Okta
- A UE está promovendo três iniciativas legislativas para lidar com a segurança de software
- NIS2: voltada a serviços importantes
- Cyber Resilience Act: voltado a quase todo software comercial e dispositivos eletrônicos
- Product Liability Directive: amplia o escopo de responsabilidade para incluir software
Vulnerabilidades vêm tanto da qualidade quanto da quantidade de código
- A segurança de software depende de dois eixos
- A densidade de problemas de segurança no código-fonte
- A quantidade de código que hackers conseguem acessar
- Quanto mais código, maior o risco
- Mesmo com baixa densidade de bugs, é possível encontrar brechas exploráveis em milhões de linhas de código
- O caso do iMessage mostra os problemas causados pela ampliação da superfície de ataque
- Mesmo iMessages indesejadas são processadas imediatamente no iPhone para gerar pré-visualizações
- A Apple oferecia suporte a vários formatos de imagem, e até PDFs contendo fontes compactadas incomuns entravam no escopo de processamento
- Esse formato antigo incluía, na prática, uma linguagem de programação, e atacantes podiam usá-lo para explorar outras fraquezas do telefone
- A Apple poderia ter reduzido a superfície de ataque limitando as pré-visualizações a muito menos formatos de imagem ou a um único formato “conhecidamente bom”
- O EU Cyber Resilience Act também estabelece que fornecedores devem minimizar a superfície de ataque
Código melhor, sozinho, não basta
- Já existem movimentos para elevar a qualidade do código
- Linguagens com segurança de memória, como Rust
- Ferramentas de reforço de segurança, como AddressSanitizer
- Fuzzers, que transformam entradas automaticamente para encontrar vulnerabilidades e bugs
- Mas muitos problemas de segurança surgem na lógica subjacente, mais do que em bugs no código em si
- A vulnerabilidade de e-mail da Barracuda surgiu porque uma biblioteca de terceiros que escaneava planilhas Excel em busca de vírus na verdade executava código
- A decisão de incluir uma funcionalidade que executa automaticamente código dentro de documentos não é resolvida mesmo que todos os bugs no código sejam eliminados
Sem saber o que está sendo distribuído
- O software moderno ficou tão grande que é difícil saber o que de fato está sendo distribuído
- Niklaus Wirth criticou, em 1995, no texto “A Plea for Lean Software”, o crescimento do software para a escala de megabytes
- Seu sistema operacional Oberon tinha 200 KB, incluindo editor e compilador
- Hoje, há projetos em que só os arquivos de configuração passam de 200 KB
- Um app típico hoje pode ser criado com base em Electron JS
- Electron JS inclui Chromium e Node.js
- Node.js dá acesso a dezenas de milhares de pacotes JavaScript
- Estima-se que o uso de Electron JS por si só possa incluir pelo menos 50 milhões de linhas de código, contando dependências
- Apps trazem centenas a milhares de pacotes auxiliares, e as dependências puxam outras dependências
- O que exatamente entra no build pode mudar todos os dias
- Alguns pacotes podem, por padrão, expor usuários a anunciantes ou data brokers
- Um app que controla dispositivos dentro de casa também pode se conectar a uma stack de software da Amazon, e essa stack também pode usar Node.js e várias dependências
- Como resultado, até para abrir a porta da garagem, mais de 50 milhões de linhas de código ativo podem estar rodando sobre várias imagens de sistemas operacionais e diversos servidores
O peso dos contêineres e da cadeia de suprimentos de dependências
- Antigamente, distribuíam-se saídas de compilador ou conjuntos de arquivos a serem interpretados, e era preciso pensar no que havia dentro do pacote durante a instalação e a configuração
- Hoje, é comum distribuir em contêineres não só o software, mas também arquivos do sistema operacional necessários para ajustar o ambiente de execução
- Na prática, muitas vezes a situação é distribuir uma imagem completa de disco de computador
- O Docker Hub tem muitas imagens com mais de 350 MB
- Contêineres podem ser usados para bons propósitos, mas, dependendo do uso real, podem aumentar muito a quantidade de código distribuído
- Também é incerto se atualizações de segurança das dependências chegam até o app final
- É difícil saber se bugs de processamento de imagem, para os quais Google e Apple correram para distribuir atualizações, ainda permanecem em apps Electron
- O ecossistema npm tem histórico de tomada de controle de repositórios de pacotes, hijacking e ressurreição de pacotes com o mesmo nome
- O PyPI também enfrenta problemas semelhantes
- Dependências exigem revisão, mas é difícil esperar que milhares delas sejam verificadas com frequência
- Reimplementar tudo por conta própria também não é a resposta, e há bons módulos, como SQLite, que provavelmente são mais seguros do que algo escrito internamente
Trifecta: uma ferramenta de compartilhamento de imagens feita com pouco código
- O Trifecta é um software independente de compartilhamento de imagens minimalista e realmente utilizável
- É possível compartilhar imagens com facilidade arrastando e soltando no navegador
- Ao usar o imgur, muitos cookies e rastreadores são instalados no navegador, e rastreadores também podem ser impostos a quem visualiza as imagens compartilhadas
- Ferramentas de compartilhamento de imagens auto-hospedadas também costumam ser baseadas em grandes frameworks, o que foi considerado difícil de confiar
- O Trifecta foi feito para ser pequeno o bastante para que todo o código possa ser revisado em poucas horas
- 1.600 linhas de código-fonte novo
- Cerca de 5 dependências importantes
- Tamanho total do código de 3 MB
- Outra solução de compartilhamento de imagens usada como comparação é distribuída como uma imagem Docker de 288 MB
- Outra solução de compartilhamento de fotos baseada em Node mostrou ter 1.600 dependências e mais de 4 milhões de linhas de JavaScript
- O Trifecta não é um site público para qualquer pessoa enviar imagens; ele é adequado para uso por empresas ou indivíduos
O problema de confundir complexidade com poder
- Uma reação comum ao Trifecta foi sugerir distribuí-lo usando um conjunto de Amazon Web Services
- Essa reação não combina com o objetivo de ser um software independente que não depende de serviços externos
- Também houve reação dizendo que o Docker estava sendo tratado de forma injusta, mas reconhece-se que contêineres podem ser usados para bons propósitos
- Niklaus Wirth apontou, em seu artigo de 1995, a tendência das pessoas de confundir complexidade com sofisticação
- Como disse Tony Hoare, há duas formas de projetar software
- Fazer o programa tão simples que obviamente não tenha erros
- Fazê-lo tão complexo que pareça não ter erros óbvios
- Wirth via a pressão de tempo como uma das principais causas do software inchado
- A pressão de tempo atrapalha o planejamento cuidadoso
- Em vez de melhorar uma solução aceitável, ela leva a acréscimos e correções rápidas
- Ela corrói gradualmente os padrões de qualidade e acabamento dos engenheiros
- A explosão do software não é uma lei da natureza; é algo que engenheiros de software devem reduzir
Reduzir a quantidade de código vira uma medida de segurança
- O mundo atual está distribuindo código demais
- A maior parte é código de terceiros
- Parte é incluída sem intenção
- A maior parte não é inspecionada o suficiente
- O resultado é uma enorme superfície de ataque, na qual uma grande quantidade de código de qualidade mediana fica exposta
- Esforços para melhorar a qualidade do código continuam, mas muitos exploits vêm de falhas lógicas, e o progresso para detectá-las é relativamente pequeno
- Só reduzir a quantidade de código exposta ao mundo já pode trazer uma grande melhoria
- O tempo para lançar produtos pode aumentar, mas a legislação que se aproxima pode fazer fornecedores tratarem a segurança com mais seriedade
- Trifecta e Oberon mostram que é possível oferecer muitas funcionalidades com código e dependências limitados
1 comentários
Comentários do Hacker News
Em A Deepness in the Sky, de Vernor Vinge, a humanidade se espalhou entre as estrelas usando apenas tecnologia subluz, e as naves interestelares aparecem como uma mistura de tecnologias antigas de vários sistemas estelares e civilizações
Os sistemas de computador também evoluíram por tanto tempo que, na maior parte, ninguém mais entende o código; ele simplesmente é usado e mais camadas vão sendo empilhadas por cima
Em especial, há um personagem que é um antigo engenheiro de sistemas, entre os humanos vivos mais velhos, por ter sobrevivido alternando longos períodos de estase e viagem; no futuro, em que todos empilharam várias camadas por cima, acaba sendo uma grande vantagem conhecer o funcionamento e as vulnerabilidades da era dele
Acho que Vinge acertou em cheio nisso
O primeiro é um mistério real, a ser resolvido pela ciência moderna e por pessoas muito inteligentes; o segundo é mais próximo de falta de interesse
Se você pagar o suficiente, um engenheiro competente vai desmontar a máquina de lavar e descobrir o defeito exato, mas ninguém quer arcar com esse custo e a pessoa simplesmente vai jogá-la fora e comprar outra
Conhecimento de software do passado claramente entra na segunda categoria. Se você investigar qualquer parte a fundo, no fim consegue entendê-la completamente, mas na maioria dos casos é muito mais barato e prático ignorar ou acrescentar mais uma camada por cima
É uma história em que a humanidade do futuro esqueceu a aritmética básica, e quando alguém a redescobre os poderosos tentam usá-la para a guerra; entendo a mensagem que ele queria passar, mas a premissa é tão irreal a ponto de ficar cômica e perder força
Para discutir mais, veja http://lambda-the-ultimate.org/node/4424
Já estamos passando por isso. Meu tio, na casa dos 60, faz manutenção de um software antigo de transporte de caminhões escrito em COBOL, e existem empregos assim com tecnologias ultrapassadas. Se tiver interesse, posso apresentar
O problema fundamental é o mesmo do caso do left-pad. As pessoas zombam de engenheiros juniores sem supervisão instalando dependências de qualquer jeito, mas depois de décadas e várias gerações de desenvolvedores, quase todo software acaba dependendo, em algum grau, de dependências impossíveis de compreender completamente
Imagine que você precise distribuir uma atualização em 2100; ela provavelmente será enviada pelo sistema de gerenciamento de dependências do npm daquela época. Ao mesmo tempo, pode haver dispositivos dependentes espalhados em escala de Sistema Solar precisando de atualização de segurança, com trilhões de aparelhos e caches intermediários cujo estado de atualização ninguém consegue confirmar. Nem dá para imaginar como seria uma árvore de dependências dessas
Também é frustrante trabalhar em um ambiente em que você precisa cavar o código do framework para chegar ao cerne do problema. Dá uma sensação de perda de tempo
O inchaço aparece na maioria das bibliotecas do npm. O autor não conhece bom design e tenta fazer com que toda biblioteca faça tudo
Diz que é uma biblioteca de conversão de codificação de strings, mas coloca no mesmo repositório carregamento de arquivos, salvamento, download pela internet e até ferramenta de linha de comando. A biblioteca deveria fazer só uma coisa, e o resto deveria ficar a cargo do usuário
Do lado de Rust também não parece melhor. Se você tentar corrigir a documentação do Rust, acaba vendo algo como 1000 crates sendo instaladas
O problema não é a linguagem, mas o fato de qualquer um poder publicar bibliotecas e, na prática, qualquer um publica mesmo. As pessoas que “só querem terminar o trabalho” escolhem a biblioteca com mais recursos e pedem ainda mais funcionalidades porque não querem escrever 3 linhas de código fora da biblioteca. É algo como: “Dá para adicionar renderização de PDF também?”
Não sei qual é a solução, mas pensei em criar um grupo e um selo de defesa do Low Dependency, para que autores de bibliotecas queiram esse selo e usuários também passem a procurá-lo ao escolher bibliotecas
Por outro lado, se você quer uma biblioteca com poucas dependências, vai acabar trazendo algumas que fazem muita coisa
Do meu ponto de vista, prefiro bibliotecas um pouco mais encorpadas, com poucas dependências, feitas por autores em quem confio. Lodash é grande, mas a versão em módulos ES6 oferece suporte a tree shaking e, na prática, funciona como a biblioteca padrão que faltava no JavaScript. O mesmo vale para date-fns em relação a Date. Para preencher as lacunas da biblioteca principal do JavaScript, coloco essas duas por padrão em quase todo projeto
Há um tempo fiz um trabalho de contrato com Ruby on Rails, e os problemas de desempenho eram tão graves que eu desenvolvia em modo release. O servidor estava num nível em que nem conseguia detectar mudanças nos arquivos para recarregar automaticamente
Um dia cansei e comecei a investigar, mas havia tantos gems envolvidos que nem lembro quantos eram. Um deles existia literalmente para economizar 3 linhas de código
Depois disso me afastei da comunidade de RoR. Recentemente peguei outro contrato de RoR pela primeira vez em anos e, embora não esteja tão ruim quanto antes, continua longe de ser bom
Algumas comunidades não respeitam em nada os riscos trazidos pelas dependências
Por outro lado, é muito prático que qualquer repositório Git possa hospedar uma biblioteca Go e que qualquer pessoa possa usá-la a partir daquela URL
Primeiro, há criadores de pacotes que querem transformar isso em carreira, e a única forma de chamar atenção é criar um monte de pacotes. Então continuam fazendo pacotes que dependem de outros pacotes que eles mesmos fizeram e tentam enfiar um ou dois pacotes úteis no código dos outros
A segunda parte são as pessoas que acreditam que resolver problemas sempre significa incluir um novo pacote. Não se importam com quantas dependências isso traz nem com a dificuldade real do problema. Então, em vez de aprender a resolver o problema, aprendem a API de um wrapper de 4 estrelas no GitHub
Idealmente, uma ferramenta dessas gastaria o tempo chato podando pacotes desnecessários, minimizando a responsabilidade de cada pacote, organizando o ambiente de forma razoável e depois armazenando tudo em cache de forma independente para eliminar a dependência de LLM. O ideal seria chamar um verificador de atualizações ou curador só quando algum problema surgisse
Sinceramente, acho que esse é um dos piores problemas do software moderno e que torna mais de 50% dos projetos inutilizáveis. É um problema tedioso, mas solucionável, então combina perfeitamente com um agente de LLM de verdade e seria de enorme ajuda se existisse
“Você já viu um avião moderno? Já acompanhou como sua linha evolui ano após ano? Já pensou que, não só nos aviões, mas em tudo o que o ser humano cria, todo o esforço industrial humano, todo o cálculo, todas as noites passadas sobre pranchetas acabam convergindo para o único princípio dominante, a simplicidade suprema?
Parece haver uma lei natural que determina que, para lapidar as curvas de um móvel, a quilha de um navio ou a fuselagem de um avião até que se aproximem da pureza primitiva das curvas do peito ou dos ombros humanos, são necessárias gerações de artesãos experimentando. A perfeição parece ser alcançada não quando não há mais nada a acrescentar, mas quando não há mais nada a remover.”
— Antoine de Saint Exupéry, Terre des Hommes
Quando se escreve algo como “pode ser necessário mais de 50 milhões de linhas de código ativo e imagens de sistema operacional de vários servidores para abrir a porta da garagem”, isso realmente soa insano
Dá vertigem pensar em quanto código está rodando na máquina em que estou digitando isto agora. Código que eu nunca revisei e que provavelmente quase nunca passou por uma revisão rigorosa
Bem, hora de voltar a instalar dependências do npm
“O software agora é considerado tão perigoso que dizem às pessoas para não o executarem por conta própria. Em vez disso, mandam deixar na mão de um provedor de ‘X as a service’ ou simplesmente da ‘nuvem’. Compare com a situação hipotética em que carros pegam fogo com tanta frequência que aconselham você a não dirigir, mas a deixar a direção com um especialista acompanhado o tempo todo por bombeiros profissionais” é uma analogia boa o bastante para eu querer reutilizá-la
Minha ex-namorada desconfiava da “nuvem” por motivos racionais, por ter crescido no antigo bloco oriental. Mas a alternativa era só torcer para não perder um notebook HP comprado pelo menor preço. Depois de um pouco de educação, pelo menos nessa parte ela ficou mais tranquila
O problema é a falta geral de educação e a pouca consideração pelas consequências disso. No fim, ou você aceita o risco, ou aprende por conta própria, ou depende de empresas de SaaS e nuvem. Vi muitas lágrimas e vi pouca gente aprender sozinha
É uma questão de responsabilidade individual, mas como ninguém quer assumir essa responsabilidade, deixar na mão de especialistas pode ser uma solução menos ruim do que confiar em si mesmo. A resposta certa é educação, mas isso é desesperadoramente difícil
O software não pode ficar mais enxuto. Para isso, seriam necessários tempo, habilidade e gente cara; não basta um monte de gente colando 12 exemplos de stacks tecnológicas diferentes para montar um Frankenstack
Sou desenvolvedor independente, e sempre vai ter alguém que aprendeu node.js no ano passado cobrando menos do que eu para montar em um dia um webapp padronizado, mas ainda vulnerável, juntando node.js, containers, qualquer serviço de banco de dados hospedado na AWS, Lambda, armazenamento de objetos, Cloudflare, YAML, React, Vite e outras dependências
Mesmo que um software enxuto, rápido, com baixo custo de execução e manutenção mais barata seja mais barato no longo prazo, é difícil escrevê-lo de forma lucrativa
Antigamente havia o sonho de ter hooks e rotinas padrão fornecidos pelo sistema para que todo mundo os usasse em interfaces e afins. Pense em coisas como Macintosh Toolbox ou QuickDraw
Diziam que o trabalho principal do desenvolvedor era escrever a lógica do programa, e que mudanças ou acréscimos deveriam ser transparentes. As chamadas de sistema fariam o mesmo trabalho sem atrito mesmo que o código interno mudasse, e novos recursos seriam um superconjunto dos recursos existentes, de modo que código antigo continuaria compilando ou executando sem problemas enquanto o software novo ganharia mais capacidades
A ideia era que isso facilitaria a manutenção, normalizaria as interfaces e também deixaria o código mais enxuto, já que dependeria bastante de chamadas de sistema. Havia um clima de que bibliotecas externas deveriam ser evitadas
Esse sonho desmoronou rápido; basta pensar em DLLs. Grande parte do gerenciamento e empacotamento de pacotes de hoje parece mais próxima de garantir que a biblioteca correta exista
Naquela época, o desenvolvimento de software em larga escala ainda estava quase na infância, então dá para entender por que não saiu como esperado. Agora há muita experiência coletiva acumulada sobre esse tipo de problema, e fico me perguntando se a conclusão foi que esse sonho é inviável em sã consciência, ou se já passamos tempo suficiente no estado bagunçado atual para isso nos empurrar rumo a uma tentativa moderna de retomá-lo
Se você quer software rápido, enxuto, estável e seguro — mesmo que seja difícil conseguir os quatro ao mesmo tempo — não tenho certeza de que a situação atual esteja caminhando nessa direção
O Lisp inicial colocava muito pouca coisa na linguagem, mas o Raku empurra para a especificação da linguagem até pequenas coisas que poderiam muito bem ir para bibliotecas npm
C deixava você decidir como compilar o código, mas a maioria das novas linguagens compiladas já vem com alguma forma de ferramenta de build junto
Há coisas bastante eficazes nesse terreno, mas elas acontecem fora do contexto de “você, a máquina, um projeto novo” que guiava o trabalho de Wirth. O problema é que isso tende a vir com o limiar de dependências gigantescas, como banco de dados ou engine de navegador, e se você não gosta do jeito como essa dependência foi feita, no fim acaba infeliz
É isso que eu continuo dizendo sobre Rust
Se 70% das velhas vulnerabilidades em C++ forem mesmo relacionadas à memória, então talvez seja possível ter 70% menos vulnerabilidades por linha de código do que em C++
Mas, se em Rust você puxa centenas de pacotes e o número de linhas de código fica 10 vezes maior, a conversa muda
30% de 100 mil linhas é maior, em termos absolutos, do que 100% de 10 mil linhas
Se algo como o QT fosse escrito em Rust, provavelmente seria, por si só, centenas de crates, mas a quantidade de código e o nível de risco assumido seriam exatamente os mesmos
Mas o problema maior são as vulnerabilidades. É melhor corrigir o bug em uma biblioteca compartilhada e consertar centenas de bibliotecas, ou corrigir centenas de bibliotecas uma por uma?
O fato de Rust facilitar puxar muitas dependências pequenas em vez de algumas dependências enormes é irrelevante. Não significa escrever mais código
Por exemplo, você conta o crate
regexdo Rust como uma dependência? Em C++, isso está na biblioteca padrãoVocê conta o Boost como uma única dependência em C++? Em Rust, isso corresponderia a umas 30 crates separadas
Quantos casos de execução remota de código programas em Rust tiveram em comparação com C++? A frequência de execução remota de código em C++ provavelmente é bem mais de 70% maior do que em Rust
Dizem que hoje em dia os apps normalmente são feitos com Electron JS, mas parece que não se sabe o suficiente que também dá para usar os controles web nativos de cada plataforma sem empacotar Electron
Fazendo isso, o app distribuído pode ficar na casa dos quilobytes. Essa abordagem dá liberdade para usar qualquer linguagem de backend ou stack tecnológica, desde que seja possível se comunicar com a web view
Hoje em dia, PWA não deveria ser viável para uma parcela bem grande dos aplicativos?
Não sei direito, mas talvez até o Discord pudesse ser um PWA em vez de um app em Electron?
A maior lacuna provavelmente seria a diferença entre o IndexedDB e algo robusto equivalente ao SQLite, mas ainda assim a maioria dos apps talvez não precise necessariamente de uma linguagem de consulta de nível mais alto do que o modelo de B-tree do IndexedDB
Mais uma saudação à filosofia suckless. Viva.
[0 ]https://suckless.org/