- A manutenção do rsync está enfrentando uma explosão de relatórios de segurança junto com controvérsias sobre o uso de IA, tornando necessários testes, cobertura de código, CI multiplataforma, varreduras de segurança e técnicas de defesa em profundidade
- A nova suíte de testes em Python substitui a estrutura anterior baseada em scripts de shell, mas o projeto e o plano de validação ficaram a cargo do mantenedor, enquanto Claude, Codex e Gemini foram usados como apoio em tarefas repetitivas
- A versão 3.4.3 foi um lançamento que priorizou correções de segurança, mas apresentou regressões em alguns casos de uso válidos porém incomuns que os testes existentes e os testes manuais não conseguiram detectar
- Embora pytest seja muito usado em outros projetos, ele não se adequava a exigências específicas da suíte de testes do rsync, por isso foi escolhida uma abordagem separada; a avaliação é que LLMs devem ser usados com cautela, mas são ferramentas úteis
- A direção futura ainda está sendo decidida entre a 3.4.4, que mitigaria regressões, e a 3.5.0, que incluiria grandes mudanças de segurança; o openrsync atualmente falha em 85 de 98 testes na nova suíte
Explosão de relatórios de segurança e reforço das defesas
- O mantenedor do rsync está passando por uma onda de relatórios de segurança, como vem ocorrendo com desenvolvedores de pacotes open source recentemente; muitos desses relatórios são gerados por IA, mas alguns também contêm análises manuais cuidadosas e de alto nível
- Com o aumento desses relatórios, o rsync passou a precisar de uma suíte de testes mais rigorosa, análise de cobertura de código, testes de CI em mais plataformas, varreduras deliberadas por problemas de segurança e técnicas de defesa em profundidade
- O mantenedor já se aposentou e gostaria de passar mais tempo velejando, mas diante do volume de trabalho necessário usou várias ferramentas de IA e afirma não se arrepender dessa decisão
Suíte de testes em Python e trabalho assistido por IA
- A antiga suíte de testes do rsync, baseada em scripts de shell, foi reescrita em Python, com o mantenedor responsável diretamente pelo projeto central e pelo plano de validação
- Claude foi usado em tarefas repetitivas, enquanto Codex e Gemini foram usados para verificação cruzada; não foi um caso de simplesmente mandar “converter a suíte de testes para Python”
- O mantenedor revisou tudo pessoalmente, gastou muito tempo de CI para ajustar o conjunto e depois migrou para uma abordagem em que a maior parte dos testes é executada em várias VMs locais para reduzir o tempo de espera do CI
- Na avaliação dele, a marcação
co-authored by claude no histórico de commits revela apenas uma parte de todo o trabalho de engenharia de software realizado
Debate sobre LLMs, escolha do pytest e regressões na 3.4.3
- A posição defendida é que LLMs não se tornam ferramentas inúteis só porque se entende como funcionam; elas devem ser usadas com cuidado, mas são úteis no ambiente atual de engenharia de software e manutenção de segurança em TI
- O rsync 3.4.3 foi intencionalmente um lançamento inclinado a priorizar correções de problemas de segurança, e nesse processo alguns casos de uso válidos, porém incomuns, acabaram afetados pelas mudanças
- Os casos de uso afetados não estavam incluídos na suíte de testes anterior do rsync nem nos testes manuais, e as regressões relatadas por issues e PRs no repositório do GitHub estão sendo tratadas em sequência
- Embora pytest seja muito usado em outros projetos, considerou-se que parte do que era necessário na suíte de testes do rsync seria muito difícil com pytest, o que levou ao desenho de uma abordagem de testes separada
Próximo lançamento e ampliação dos testes de segurança
- Os relatórios de segurança continuam chegando, e vários trabalhos relacionados a CVEs estão em andamento neste momento
- Outros desenvolvedores com capacidade de desenvolvimento de sistemas e conhecimento em segurança se juntaram ao esforço, e alguns deles ganharam visibilidade justamente por causa da indignação recente
- A próxima decisão está entre a 3.4.4, que mitigaria algumas regressões, e a 3.5.0, que traria mudanças muito maiores; a 3.5 elevaria bastante o padrão de segurança do rsync, mas é uma versão com mudanças de grande escala
- Para aplicar rapidamente um conjunto grande de mudanças, um software como o rsync precisava de uma suíte de testes abrangente, e a reescrita da nova suíte surgiu dessa necessidade
- A versão 3.5 deverá incluir testes adicionais voltados a questões de segurança
Comparação com openrsync e pedido de revisão de código
- Diante do movimento de empacotar o openrsync para plataformas específicas, a reação foi dizer que a nova suíte de testes do rsync poderia ser aplicada ao openrsync
- O exemplo de execução é o seguinte comando
./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp
- O openrsync atualmente falha em 85 dos 98 testes; muitas falhas se devem a recursos que não existem no openrsync, mas a avaliação é que isso não é um bom resultado
- Em vez de expressar ainda mais indignação, o pedido é que as pessoas revisem de fato o código publicado e façam críticas construtivas
1 comentários
Comentários no Lobste.rs
Pelo trecho citado, parece que o autor quer sair para velejar, mas sente pressão para manter o projeto, e enxergou no uso de LLM uma solução para conseguir fazer as duas coisas
Não há problema em curtir a aposentadoria e a vela sem corrigir bugs, e também não há problema em deixar de corrigir bugs em um projeto de código aberto. Basta deixar isso claro de forma pública e transparente. Como se dizia antes, “patches welcome” já basta. Isso é ainda mais verdade se empresas com muitos recursos dependem do projeto
Eu queria que mais mantenedores e desenvolvedores pudessem curtir a aposentadoria e a vela sem a pressão de ter de contar com a “ajuda” de LLMs para manter software livre. Ainda assim, se ele quiser experimentar LLMs no projeto rsync, essa é uma escolha dele. Isso continua valendo mesmo que outras pessoas, inclusive eu, discordem
Seja qual for o motivo, as pessoas que atormentam desenvolvedores de código aberto parecem esquecer que software livre e de código aberto gratuito não é um produto, e sim um presente
Quem está de fora só assistindo pode fazer um fork se não gostar. O Andrew pode trabalhar no projeto do jeito que quiser, e nossos comentários e opiniões não são necessariamente necessários
A parte esperançosa é que talvez apareça outra pessoa para assumir a manutenção do rsync no longo prazo. O Tridge já transferiu isso para um novo mantenedor no passado
Ouvi uma apresentação sobre casos em que a OpenJS Foundation forneceu financiamento e apoio à transição para alguns projetos, ajudando a sair de um modelo com um único mantenedor para manutenção em equipe, e escrevi um texto para a LWN sobre isso, que deve ser publicado hoje. Projetos como o rsync precisam muito mais desse tipo de apoio
Questões de segurança trazem muita pressão, têm alta visibilidade e muitas vezes ficam distantes do cerne do projeto que interessa ao mantenedor
Há muitas responsabilidades na manutenção, e nem todas são agradáveis, mas sou grato quando mantenedores de software livre e de código aberto assumem até esse tipo de trabalho. Não parece haver muita gente disposta a fazer isso
Pode ser que, sem ajuda de LLM, o custo para atingir determinado objetivo seja alto demais, e com ajuda de LLM ele passe a ser razoável
Vendo pelo lado positivo, isso permite que um mantenedor de equilíbrio entre trabalho e vida pessoal mais saudável reduza a carga de trabalho com LLM e ainda assim alcance com mais facilidade os objetivos que deseja
O trecho citado seletivamente é só uma parte da introdução, e este texto claramente foi escrito com cuidado e nuance, não sendo um texto básico sobre manutenção de código aberto
Mais estranho ainda é ter omitido o contexto imediatamente anterior ao trecho. Com a explosão no número de relatos, foi preciso elevar bastante a linha de defesa do rsync, com necessidade de uma suíte de testes muito mais rigorosa, análise de cobertura de código, testes de CI em mais plataformas, investigação de problemas de segurança e adição de técnicas de defesa em profundidade
Neste caso o autor está aposentado, mas em outros projetos de código aberto pessoas com emprego ou outras obrigações podem ser arrastadas por um aumento semelhante de carga de trabalho. Sinceramente, acho desconcertante que esse comentário tenha recebido tantos votos; não parece um texto escrito de boa-fé. No máximo, soa só um pouco melhor do que um comentário preguiçoso deixado por alguém que correu para responder depois de ler apenas o título
Não pretendo justificar nem aprovar assédio, mas falta algo nessa defesa
A explicação é que o autor fez o design para vibe coding, revisou o código resultante, entende de código e de chatbot, tratou o vibe coding com cautela e tentou equilibrar segurança e regressões de funcionalidade. Parece plausível, mas na prática houve regressões, e o autor não chega à raiz do motivo
Ele disse que “ferramentas de IA são fortes em tarefas simples, então delegou esse tipo de trabalho”, mas isso não procede. Chatbots na prática são ruins de escrita. Esse é o ponto central, mas o autor parece nem perceber isso
Seria bom confirmar se os números realmente aumentaram recentemente. Regressões em si não são raras, e talvez as pessoas só estejam procurando um pretexto para atacar o Andrew
O autor reconheceu que houve regressões em alguns casos de uso na release rsync 3.4.3, explicou que nessa release deliberadamente deu mais peso à correção de problemas de segurança e que alguns casos de uso válidos, porém incomuns, foram afetados pelas mudanças
Esses casos não estavam cobertos pela suíte de testes existente do rsync nem pelos testes manuais que ele próprio executou, e ele disse que está lidando com as regressões agora, agradecendo a quem relatou isso por issue ou PR no repositório do GitHub. Também pediu desculpas caso o caso de uso de alguém tenha sido afetado e disse que, se a pessoa preferir aceitar o risco de segurança, pode usar a release anterior
Tenho ouvido repetidamente há uns seis meses coisas como “o mundo da engenharia de software mudou dramaticamente nos últimos meses” e “o mundo de manter software em meio à segurança de TI e a uma enxurrada de relatórios mudou completamente nas últimas semanas”, e isso já cansou
Se a causa dessa enxurrada de relatórios forem os LLMs, tentar encontrar a solução nos próprios LLMs parece uma direção absurdamente errada
Ainda assim, dá para acreditar imediatamente que manter qualquer coisa popular hoje em dia seja horrível. Talvez, para ele, o melhor seja simplesmente recuar e aproveitar uma aposentadoria de verdade, em vez de espremer ainda mais um tempo de computação limitado
Se fosse uma ferramenta útil nem que fosse por metade do que as pessoas afirmam, acho que essa utilidade falaria por si só
Ainda assim, vale a pena ouvir alguém como Tridgell. E a “inundação” de relatórios de segurança precisa ser levada a sério. Não importa quem ou o que encontrou, um problema de segurança continua sendo um problema de segurança. Por isso, este texto parece diferente da ofensiva cansativa que normalmente se vê
No fim, isso pode nos colocar numa espiral descendente de dependência cada vez maior de LLMs
Por que isso seria a direção errada? Você quer dizer que seria melhor se ninguém tivesse LLMs?
Desenvolvimento assistido por LLM não precisa necessariamente resultar em “lixo”
Fico grato por este texto ter sido escrito e compartilhado. Em especial, chamou atenção a parte sobre estar em dúvida entre mitigar algumas regressões com o 3.4.4 ou seguir para o 3.5.0, que traz mudanças bem maiores
Se o autor estiver lendo, aqui 3.4.4 parece a abordagem certa. Depois de regressões no último release, ir direto para um grande 3.5.0 vai parecer imprudente para muita gente. Se as pessoas entenderem mais facilmente a diferença, as preocupações diminuem
Sobre a parte em que ele diz que talvez tenha sido uma má ideia tentar desenvolver primeiro, de forma pública no master, a estrutura central da nova suíte de testes, já que isso provocou raiva: não parece que reduzir a transparência vá melhorar a percepção ou a reação. Na melhor das hipóteses, só adia uma reação ainda maior
Não é justo dizer para rodarem a nova suíte de testes do rsync no openrsync. O samba rsync está no protocolo 32 e o openrsync no protocolo 27, além de ele nem alegar completude de funcionalidades
Medium e Cloudflare, que combinação horrível, coisas que não deveriam se misturar
https://archive.is/qbyVA
Manter software de código aberto é um trabalho ingrato. Tridge tentou corrigir a dívida técnica da suíte de testes e responder com responsabilidade à enxurrada de CVEs detectados por LLM, mas parece ter sido atingido pela lei de Hyrum. O plano do 3.4.4 é a opção menos ruim, e no fim acho que ele vai ter que seguir em frente com isso
Tenho sentimentos divididos sobre isso. Por um lado, acho que a segurança só pode ser garantida quando uma pessoa escreve o código diretamente
porque, enquanto escreve, ela pensa sobre aquele código e encontra erros mais cedo. Eu escrevo muito melhor quando estou codando do que quando estou revisando. Durante a revisão, muita coisa simplesmente passa batido porque eu não pensei cuidadosamente em cada linha
Por outro lado, deixando de lado o fato básico de que assédio é inaceitável, Andrew tem o direito de tocar seu projeto no tempo livre da forma que quiser. Se ele quiser usar LLM, eu discordo, mas o projeto é dele e isso está a seu critério. Se eu não gostar, devo migrar meus backups para restic ou borgbackup, ou fazer um fork do rsync
Para deixar claro, eu não sou contra vibe coding em si. Na empresa, estão meio que nos forçando a usar isso, e para escrever código cola chato e nada novo, que hoje em dia é a maior parte do meu trabalho, até que serve. Só não uso no meu tempo livre
rsynctambém não é exatamente a solução idealporque não ajuda a restaurar quando o conteúdo dos arquivos é corrompido. Uma ferramenta como restic é muito melhor e ainda guarda versões anteriores dos arquivos para lidar com esse tipo de caso. Na prática, também rastreia exclusões, então sabe quais arquivos já não são mais relevantes
Tenho experiência com segurança de aplicações, consigo farejar alguns exploits e também encontrá-los em revisão. Mas não faço isso tão bem quanto os LLMs de ponta hoje, quando ficam iterando no estilo “procure casos ainda mais patológicos”
Em softwares tão populares assim, encontrei sem muito esforço problemas no meu código, nas bibliotecas usadas e em implementações alternativas. O tempo e a persistência que um humano consegue dedicar nem se comparam
Em toda a organização, há uma ampla implantação de software de segurança para prevenir, detectar e responder a problemas. Em cada área sempre há lacunas e mais trabalho a fazer. Uma organização pode preferir adotar melhorias na postura de segurança, mesmo sabendo que não será perfeita, em vez de não melhorar nada. O compromisso oferecido pelos LLMs faz parte disso
Esse ponto de equilíbrio varia conforme o contexto, mas raramente chega a “todo código deve ser escrito à mão”
Isso também se aplica a servidores como o rsync. Como diz o autor, talvez seja necessário um grande refactor para torná-lo mais robusto e resiliente. Se for possível usar um LLM para refatorar na direção de separação de privilégios e criar uma base de código confiável menor, talvez dê para aceitar alguns bugs fora desse escopo
Não conheço o contexto específico do rsync, mas acredito que o autor esteja tomando a melhor decisão para o projeto e para os usuários dentro dos recursos limitados que esses projetos costumam ter
Em compensação, o rclone tem paralelismo e usa a largura de banda de rede disponível de forma muito mais eficiente
Isso dá um limite superior para os tipos de problemas que podem existir
O limite inferior são bugs e vulnerabilidades que eu posso encontrar, que outra pessoa pode encontrar, ou que outra coisa, como um LLM, pode encontrar
A situação em que uma pessoa revisa o próprio código em C, como no rsync, dificilmente seria considerada uma boa posição nesse espectro. Não estou querendo culpar o Andrew de forma alguma
Tenho simpatia por um mantenedor aposentado que quer sair para velejar, mas não acho que esse contexto mude algo de forma fundamental
Tridgell não nos deve trabalho algum, e tem liberdade para se aposentar e ir velejar. Se é isso que ele quer fazer, espero que dê tudo certo. Entendo o senso de responsabilidade, mas, se li bem nas entrelinhas, parece que ele sente isso como um certo peso
Mas rsync é um software crítico, e acho que quem se propõe a mantê-lo precisa seguir um certo padrão de qualidade. Se o trabalho do mantenedor não atinge esse padrão, isso é um erro. Ainda assim, isso não justifica assédio. Dizer que algo é um erro não significa que a pessoa que o cometeu seja má, nem que eu não tenha empatia por ela
Então a pergunta é se o trabalho feito com ferramentas de codificação por IA atendeu ao padrão. E o padrão é, mais ou menos, “é melhor ter esse trabalho nessa qualidade do que não ter trabalho nenhum?”. Se melhora o software, deve continuar; se o piora, deve parar. Não afirmo que seja uma definição brilhante, mas acho que é a correta
Não temos o direito de exigir trabalho extra de Tridgell, mas ainda assim há espaço para dizer “isso está piorando a vida dos usuários”, se for esse o caso
Sinceramente, ainda não tenho uma posição totalmente consolidada sobre como julgar esse trabalho. Houve regressão, e Tridgell a descreveu como um caso de borda, mas sem mais contexto não sei como comparar o impacto dessa regressão de caso de borda com o valor de corrigir possíveis problemas de segurança
Alguém pode lembrar de “WITHOUT ANY WARRANTY”, mas essa cláusula não tem relação aqui. É uma isenção de responsabilidade legal, não uma renúncia ao orgulho artesanal ou à expectativa não jurídica de fazer o melhor possível. Este comentário também é fornecido “WITHOUT ANY WARRANTY”, mas se eu errar, obviamente posso ser criticado
Não foi o autor que transformou isso em software crítico. Se você ou outra pessoa usa isso, a responsabilidade é do usuário. Se o software não funciona como esperado, faça um fork ou substitua. O que não dá é tentar obrigar a pessoa a agir no seu ritmo
Contexto para quem perdeu o relato original da regressão: https://github.com/RsyncProject/rsync/issues/929
O relato da issue é uma captura de tela de um post no Mastodon, e depois disso vieram mais de 300 comentários de discussão
Não explique, apenas siga fazendo como sempre fez. Quem não gosta vai continuar não gostando
As pessoas começaram a não gostar desde que pararam de escrever assembly, e não vão parar tão cedo