Os acessos vindos de bots (automatizados) já são 57,5%, de acordo com os dados mais recentes da Cloudflare, um dos maiores funis dos conteúdos da web moderna. É a primeira vez na história em que isso acontece, e antecipou até mesmo a previsão pessimista do CEO da empresa, que previa para o ano que vem essa ultrapassagem.

E não são aqueles bots ~tradicionais (rastreadores de sites, indexadores de pesquisa, bots de DDoS, etc.): a Cloudflare sublinha que está mapeando agentes que navegam na web fingindo serem pessoas, em nome de pessoas, e que _isso_ já está em grande escala, em tarefas como comparar preços, pesquisar voos, pedir refeições ou lidar com interações de SACs e atendimento a clientes em geral.

Em termos de tempo on-line, entretanto, os humanos continuam ~ganhando.

Referência: ‘Bots have now passed human traffic online,’ Cloudflare boss laments — says agentic traffic wasn’t expected to eclipse real people until next year

O artigo "Cloudflare confirma: a Internet já tem mais tráfego de bots do que de pessoas" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Isso não impede minha rejeição (na verdade, aumenta o tamanho da decepção, embora eu não negue que ele tenha o direito de se posicionar como bem entender) à resposta que ele publicou sobre a recente controvérsia causada pelas regressões no código do rsync, iniciadas quando ele resolveu aplicar vibe coding ao seu desenvolvimento, como vimos neste post anterior aqui no BR-Linux: “Novas versões do rsync trazem bugs críticos surpreendentes e foram feitas com IA”.

A resposta dele me desaponta por vários motivos, mas o principal é se esforçar para desqualificar coletivamente quem criticou a situação.

A resposta dele me desaponta por vários motivos, mas o principal é ele concentrar boa parte dela em uma visão que desqualifica coletivamente (com expressões como “uma enxurrada de lama dos assim chamados especialistas da internet”) quem criticou a situação atual do código – que objetivamente não é boa, ainda mais se comparada ao histórico do próprio projeto.

A resposta dele também me preocupa, porque ele confirma que preferiu uma estratégia em que a IA não apenas escreve o código novo para o rsync, mas escreve os testes que validam esse código novo. O resultado nós vimos nas atualizações recentes (e não surpreende, dado o método), Mas Tridge defende longamente essa escolha, e rejeita (literalmente) os PhDs que apontam os riscos dessa estratégia, como se estivéssemos falando de um risco teórico, e não da sua materialização na forma de regressões em um sistema previamente estável.

A resposta de Tridge também me causa rejeição porque ele – que acusou os outros de jogarem lama – aproveitou para jogar lama no openrsync (que eu uso há anos, e agora vou usar em mais máquinas) como alternativa a quem deseja migrar do seu projeto, com o argumento de que não passa em boa parte da sua nova suíte de testes (aquela que ele acabou de pedir para a IA criar…).

Esse argumento dele é duplamente ruim: primeiro, porque desconsidera que o openrsync atualiza segurança e compatibilidade, mas intencionalmente congelou sua base nos recursos e interfaces do rsync de uma versão estável de um bom tempo atrás (é com o rsync 3.1.3, de 2018), portanto naturalmente não passaria em testes desenhados para atestar compatibilidade com versões posteriores. E segundo, porque no mesmo post, Tridge sugere aos descontentes que instalem versões anteriores do próprio rsync (mesmo sabendo que elas possuem falhas de segurança, que foi o que o motivou a usar vibe coding no projeto, conduzindo à situação atual).

Em suma, uma má resposta, que não resolve nenhum problema, por mais que o autor tenha direito de se sentir injustiçado ou desvalorizado pela enxurrada de críticas.

Mas há algo que me dói um pouco mais, e aí é a favor do Tridge, e não contrário ao seu posicionamento: ele abre o texto dizendo que está aposentado, e prefere ir velejar do que ficar cuidando de softwares. Ao longo do texto, ele retorna a essa ideia. É evidente o quanto ele está em busca de uma alternativa que permita viabilizar isso (e pensou ter encontrado na IA).

Eu concordo com ele quanto ao desejo: ele tem direito, e merece poder desfrutar da aposentadoria. Sabemos que ele já tentou passar o rsync para outro mantenedor, mas não deu certo, e o projeto voltou a ele.

Tomara que uma próxima tentativa dê mais certo, Tridge possa se aposentar efetivamente, e deixe o projeto em boas mãos.

O artigo "Criador do rsync responde (mal) à controvérsia sobre as regressões causadas pelo seu uso de vibe coding" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

O BR-Linux, que completa 30 anos em novembro deste ano, deseja feliz aniversário ao Phoronix, que é o aniversariante do dia. Parabéns!

Hoje completam-se 22 anos desde o dia em que Michael Larabel criou o Phoronix, inicialmente voltado a reviews de hardware rodando Linux, e hoje um dos principais recursos internacionais de notícias e comentário especializado sobre a cena open source.

Parabéns ao Michael pela resiliência, pela qualidade do resultado, e por continuar resistindo a se juntar a um cenário cada vez mais caracterizado por veículos que copiam conteúdo alheio ou se limitam a transcrever releases recebidos das assessorias de imprensa das marcas, ou mesmo a vender seu espaço para publicar propaganda fingindo ser conteúdo editorial.

Referência: phoronix.com

O artigo "Feliz aniversário, Phoronix – 22 anos de qualidade na cobertura do cenário open source" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

A turma do Retrópolis certamente vai identificar um padrão 👇🏻 ao saber que a Microsoft anunciou ontem o lançamento do componente 'Coreutils for Windows', levando ao sistema deles uma implementação nativa, e oficialmente mantida, de uma série de comandos e utilitários herdados do Unix dos anos 1970 e 1980, e que a partir de 1990 evoluíram como parte do GNU Coreutils (que só ganhou esse nome a partir de 2002, porque antes era dividido entre textutils, shellutils, fileutils e mais alguns pacotes isolados).

A implementação da Microsoft usa a mesma estratégia do BusyBox: um único executável, e inúmeros links apontando para ele, com nomes distintos como cat, cp, mv, ls, base64, pwd, tee e muitos mais. E o pacotão da Microsoft usa a reimplementação das coreutils em Rust (aquela mesma que a Canonical incluiu cedo demais como default no Ubuntu), e também incluiu alguns softwares extras, relacionados aos comandos find e grep.

Alguns dos comandos, que dependem de funcionalidades do POSIX que não são nativas no Windows, não foram incluídos na versão atual – assim, não estão disponíveis itens como chmod, chown, chroot, nohup, tty, kill e timeout. Quanto aos que foram incluídos, a Microsoft já avisa para não esperar compatibilidade plena e imediata, porque até a forma como os 2 sistemas identificam o final de cada linha de texto é diferente, e certamente haverá outras diferenças mais profundas a serem identificadas para corrigir ou conviver.

E o padrão retrô que eu mencionei acima é este: os comandos mais essenciais do Unix sempre acabam dando um jeito de chegar às plataformas da Microsoft, cuja linha de comando suporta os recursos necessários de redirecionamentos e pipes, mas não vem com a mesma riqueza de filtros para explorá-los.

Eu já fui usuário dessa ideia ainda no século XX, com o pacote MSX-DOS Tools (lançado em 1987 pela Ascii Corp., parceira da Microsoft no Japão), que incluía no MSX-DOS da Microsoft vários comandos do Unix como grep, head, tail, tr, uniq, wc, sort e patch.

Referência: infosec.exchange

O artigo "Microsoft adere e anuncia a chegada oficial do Coreutils ao Windows, com cat, cp, ls, tee e mais" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Quase não há novas funcionalidades nessa versão, o que não significa que você não deva instalá-la, já que alguns dos bugs corrigidos tem implicações diretas em segurança do sistema, e em estabilidade das transferências de arquivo – incluindo um bug quase sádico, que às vezes deixava um download estacionado permanentemente em 99%, sem jamais indicar sua conclusão.

Referência: techhub.social

O artigo "Transmission 4.1.2: nova versão do popular cliente BitTorrent corrige bugs" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Sabemos que o Ubuntu não deseja ser, nem nunca desejou, uma continuidade daquela visão do que seria uma distribuição Linux ortodoxa (melhor representada por projetos como o Slackware); a esta altura já não surpreende que esteja a cada 4 anos mudando quem é o seu público-alvo (já foi mobile, já foi a turma da convergência de telas), nem que abandone na chuva o público-alvo anterior a cada troca de foco – que é a parte que me levou a abandoná-lo há 16 anos (hoje minha distribuição do dia a dia é o Debian, nunca fui triste), após uma regressão grave na qualidade do instalador, que me custou dados e muito stress, na época em que eles resolveram se concentrar em ter seu próprio ambiente gráfico.

E a palestra do CEO da Canonical e ex-astronauta Mark Shuttleworth deixou clara, mais uma vez, essa desconexão com o legado, pois ele falou com todas as letras: para esse mundo novo que ele enxerga como o futuro para o Ubuntu, não há alternativa exceto “os usuários irem além do apt e rpm, para snaps assinados, atualizados automaticamente e orientados por políticas” – formato e modelo de distribuição de pacotes que a empresa dele prefere há tempos, e agora justifica com a palavra mágica “IA”.

Outro ponto em que o ex-astronauta apresenta a mesma desconexão em relação ao modelo ortodoxo de Linux é a insistência em containers. Para ele, containers são a solução desde a base, com "tudo rodando em caixas de ferramentas isoladas em camadas", o que seria uma solução ideal para a sua visão em que seu público-alvo “deseja rodar milhares de agentes”, e assim cada instância do Claude e do Copilot terá completo isolamento.

Essa solução containerizada é complementada pelo 'Workshop', um modelo que permite ao administrador hierarquizar os tokens, senhas e acessos, passando a cada agente apenas o conjunto que ele precisa ter, e reduzindo assim a atual onda de ataques em que agentes roubam conjuntos inteiros de credenciais de máquinas de desenvolvimento ou acessíveis por elas.

Esse público-alvo a que ele está se dirigindo existe? Certamente, e parte dele deve até mesmo estar lendo o BR-Linux neste momento, enquanto acredita no acerto das medidas da Canonical – e pode até estar certo, quanto ao sucesso mercadológico do contexto tecnológico que a empresa adotou, pois nada está definido no momento.

A certeza que eu tenho, entretanto, é que eu não sou parte desse público-alvo, e isso não mudaria, caso eu fosse fã de IA no desenvolvimento de software. No nível sistema operacional, eu prefiro interfaces e conhecimentos estáveis ao longo de muitos anos, e não uma sucessão de tentativas periódicas de me levar a adotar um novo ambiente, um novo padrão de empacotamento, um novo conjunto de coreutils etc., enquanto vejo os recursos e requisitos que eu valorizava sendo largados pelo caminho.

Referência: tech.lgbt

O artigo "Ex-astronauta da Canonical afirma: Ubuntu é o sistema operacional para a era dos agentes de IA" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Por enquanto funciona apenas em modo local (ou seja, várias pessoas se alternando em frente a um mesmo terminal), mas a expansão para partidas entre jogadores remotos já esta planejada. E achei bem bonitinha a interface TUI já implementada!

O desenvolvedor não buscou permissão para usar a marca registrada, então nada de chamarmos de Settlers of Catan – o nome é El Poblador! Quanto ao código, entretanto, está tudo bem definido: é open source e free software, com a licença EUPL 1.2, da União Europeia – mesma licença do Pi Hole, entre outros projetos.

Referência: techhub.social.

O artigo "El Poblador: Jogue Catan no seu terminal" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

“A Red Hat está ciente dos relatórios de segurança sobre certos pacotes npm em nosso ecossistema de ferramentas de desenvolvimento. Iniciamos imediatamente uma investigação e removemos os pacotes do registro npm”, diz o comunicado que a empresa está distribuindo à imprensa.

A Red Hat também diz que os pacotes estão limitados ao uso no desenvolvimento interno, e que "não identificou nenhum impacto a sistemas de clientes ou parceiros, ou a ambientes de produção internos", e se negou a responder sobre como foi que os pacotes foram infectados.

Já as empresas de segurança Aikido e OX Security, que identificaram e reportaram a situação, dizem que os pacotes em questão (96 versões de um total de 32 pacotes) recebem cerca de 117 mil downloads semanais, e que o malware inserido nos pacotes foi projetado para roubar credenciais de desenvolvedores, segredos de nuvem, chaves SSH, tokens CI/CD e outras informações confidenciais.

Está mesmo sendo um ano distópico para o cenário da tecnologia da informação em geral, e da segurança digital (e da privacidade) em particular: essa mesma família de malwares já foi encontrada também em pacotes mantidos por organizações como Bitwarden, SAP, Mistral, TanStack, OpenAI e o próprio GitHub.

Neste momento, a orientação a quem instalou algum das versões afetadas é rotacionar imediatamente todas as credenciais, segredos e tokens utilizados pelo código no dispositivo infectado.

Via BleepingComputer: Red Hat npm packages compromised to steal developer credentials.

O artigo "Malware de roubo de credenciais é encontrado em 32 pacotes npm da IBM Red Hat" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Rust Coreutils, você sabe, é uma implementação em Rust de uma série utilitários fundamentais da linha de comando, fornecidos pelo pacote GNU Coreutils, como cp, mv, rm, ls, cat, head, tail, wc e chmod.

Esse tipo de componente é um caso de uso ideal para uma reescrita que aproveite as vantagens de segurança e desempenho que o Rust traz, e o projeto busca oferecer substitutos compatíveis para essas ferramentas.

Mas compatibilidade é mesmo o conceito-chave aqui: o ecossistema tem décadas de acervo de scripts e bibliotecas fazendo uso das interfaces e formatos (documentados ou não) adotados pelas ferramentas originais, e qualquer mudança nas entradas ou nas saídas gera efeitos inesperados, imprevisíveis, e surpreendentes, de um jeito ruim.

Os desenvolvedores estão cientes e atentos para isso, o que talvez não seja o caso de alguns distribuidores, como os do projeto Ubuntu, que decidiram colocar desde o ano passado esse código em versões de produção, decisão que rejeito (mas não coloco na conta dos desenvolvedores, e sim dos distribuidores) – concordo 100% com a medida, mas não com a oportunidade, já que sacrifica a estabilidade e compatibilidade de hoje em prol de vantagens que serão colhidas apenas pelos usuários no final do ciclo de suporte da atual versão LTS.

Quanto à nova versão, o Changelog indica que além de melhorias de arquitetura de segurança, tivemos melhorias de desempenho (em comandos como cat, wc, head, tail, yes, cp, tee e unexpand), de compatibilidade (ls, numfmt, date, tr, cksum, factor, head, stat e sort) e suporte a modelos cross-platform.

O artigo "Rust Coreutils lança versão 0.9 e não tem culpa da pressa dos distribuidores destemidos demais" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

 
Consulte também a programação completa deste evento, que aconteceu no sábado.

Parabéns aos organizadores e a todo mundo da Cumbuca Dev. Que venham outras edições!

O artigo "Assista: Nosso Open Source Summit, encontro aberto sobre FLOSS" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Ou seja: a IA entrou em cena em um utilitário que fundamenta os backups de muitos de nós, e entrou com aquele workflow típico: ao arrumar um bug, gera outros dois em partes do código que nem estavam relacionadas, e a gente começa a ver um padrão de patches feitos por IA, que estão lá para consertar bugs introduzidos por patches anteriores, também feitos por IA. A thread do link acima (assim como outros locais também) esmiuça isso um pouco mais detalhadamente, relatando outras regressões encontradas em versões recentes, numa inspeção inicial do código.

Como case de adoção de IA, é interessante para estudo, talvez vire caso antológico até, já que é um desenvolvedor experiente e renomado, e um software altamente popular. Escolha dele, claro. Do ponto de vista de quem recebe e usa um software previamente estabilizado, entretanto, provavelmente atende mal e leva a procurar alternativas.

A situação ainda está se desenvolvendo, possivelmente haverá respostas dos envolvidos, e mais detalhes, contrapontos ou explicações surgirão. Convém acompanhar. Mas vale lembrar: existe o fork openrsync, integrante da árvore de projetos do OpenBSD (sendo, portanto, irmão do openssh). Eu uso há anos.

O artigo "Novas versões do rsync trazem bugs críticos surpreendentes e foram feitas com IA" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Dependendo da configuração de recursos como AppArmor ou SELinux, o bug pode ser mitigado, mesmo quando presente. E ele está presente na configuração default de uma série de versões de distribuições como Linux Mint Cinnamon, CentOS Stream 9, Rocky Linux 9, Kali Linux headless, AlmaLinux 9.7, SLES 15.

Em várias outras distribuições, o bug não é instalado por default, mas estará presente se o usuário tiver instalado o cifs-utils. Nesse grupo, temos: Ubuntu 18.04/20.04/22.04 Desktop/Server, Ubuntu 24.04 Desktop minimal/full e Server, Debian 11/12/13 netinst standard e GNOME/KDE/standard/XFCE, CentOS Stream 9 Cinnamon/KDE/MATE/XFCE, Rocky Linux 9 KDE/Workstation-Lite, openSUSE Leap 15.6 GNOME/KDE, openSUSE Tumbleweed GNOME/KDE, Rocky Linux 8 GenericCloud, Oracle Linux 8/9 KVM, Amazon Linux 2023 KVM.

O link acima inclui, ao final, os passos para mitigação imediata (desativar o módulo do kernel ou desinstalar o pacote cifs-utils deve bastar para afastar o risco imediato).

O artigo "CIFSwitch: vulnerabilidade dá acesso indevido de root em diversas distribuições" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Era a resposta, redigida inicialmente por mim e encaminhada à revista por vocês, às acusações infundadas contra o software livre, que a revista havia publicado na quinzena anterior, em uma matéria que era sobre questões partidárias e de gestão pública, não tecnológica.

Antes disso, eu aguardei resposta oficial, sugeri à galera que dizia representar o movimento software livre junto ao governo federal para que tomassem alguma providência, pedi ao ministério correspondente que houvesse resposta oficial, e não veio.

Aí promovi a nossa reação, com apoio de vocês. Os editores da revista acataram e ainda elogiaram. Mandamos bem!

Sobre as questões originalmente levantadas pela revista, também encaminhei nossas perguntas a respeito, ao Ministério competente. O ministério confirmou recebimento e disse que nos responderiam, mas estamos no aguardo até hoje.

O artigo "20 anos hoje: o dia em que a comunidade do BR-Linux defendeu, na Revista Veja, o software livre" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Segundo o artigo publicado, veja só, pelo Wall Street Journal, o poço da Red Hat:

"servirá como uma camada de coordenação de segurança, utilizando capacidades avançadas de IA para identificar, testar e corrigir vulnerabilidades de segurança em grandes volumes de código-fonte aberto. Os recursos estarão disponíveis por meio de assinaturas comerciais, permitindo que as empresas reportem bugs em estruturas de código aberto e recebam patches validados e prontos para produção que podem ser integrados diretamente em suas cadeias de fornecimento de software"

Esse poço tem a IA nas duas pontas: a da demanda – porque oferece os serviços justamente a organizações que usam o código aberto na infraestrutura de suas iniciativas em IA –, e o do contexto, porque capitaliza a ideia de que “novos modelos de IA tornam mais fácil que os adversários encontrem e explorem vulnerabilidades de software”.

Segundo o artigo do WSJ, a IBM/Red Hat informou que já começou a cavar o poço, com um grupo de clientes que inclui: Bank of America, Citi, Goldman Sachs, Morgan Stanley, Visa e Wells Fargo.

O artigo "Poço da distopia: IBM e Red Hat prometem alocar US$ 5 bilhões e 20.000 profissionais à segurança particular do código aberto" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.

Eu sou muito simpático ao tema, e tive a oportunidade de ter serviços finger e gopher ativos antes da popularização da web – em meados da década de 1990, administrei 2 servidores gopher antes de administrar o primeiro servidor web da minha carreira. Boa parte dessa forma de ver o mundo acabou se cristalizando nos princípios que definiram o Axe, CMS que eu criei para hospedar o BR-Linux e meus outros sites, sem ser voltado a essa web meio distópica que temos hoje em dia.

O artigo do Brennan faz um bom trabalho ao explicar o gemini (que não é o serviço de geração de conteúdo enlatado do Google, neste caso, e sim um protocolo moderno para suprir a mesma lacuna preenchida pelo Gopher, cuja evolução praticamente parou assim que a web baseada no http decolou.

Se você não sabe do que estamos falando, este portal permite acessar todos esses protocolos no seu navegador, e tem links para alguns sites de exemplo.

Saiba mais: Gemini, Gophers, and Fingers. Oh My! Alternative Internets Beyond HTTPS.

O artigo "Dias de um futuro esquecido: finger, gopher e o gemini (não aquele, o outro!)" foi originalmente publicado no site BR-Linux.org, de Augusto Campos.