- La maintenance de rsync fait face à une explosion des rapports de sécurité, doublée d'une controverse sur l'usage de l'IA, ce qui a rendu nécessaires une suite de tests plus robuste, la couverture de code, une CI multi-plateforme, des scans de sécurité et une défense en profondeur
- La nouvelle suite de tests en Python remplace la structure existante en scripts shell, mais la conception et le plan de validation restent sous la responsabilité du mainteneur, tandis que Claude, Codex et Gemini ont été utilisés pour assister les tâches répétitives
- La version 3.4.3 était une release priorisant les correctifs de sécurité, mais elle a introduit des régressions sur certains cas d'usage valides mais atypiques que les tests existants et les tests manuels n'avaient pas détectés
- pytest est largement utilisé dans d'autres projets, mais ne correspondait pas à certains besoins spécifiques de la suite de tests de rsync, d'où le choix de concevoir une approche séparée ; les LLM doivent être utilisés avec prudence, mais sont jugés utiles
- La suite se décide entre une 3.4.4 destinée à atténuer les régressions et une 3.5.0 incluant de gros changements de sécurité ; openrsync échoue actuellement à 85 tests sur 98 dans la nouvelle suite de tests
Explosion des rapports de sécurité et renforcement défensif
- Le mainteneur de rsync vit actuellement la même situation que d'autres développeurs de paquets open source ces derniers temps : un afflux massif de rapports de sécurité, dont beaucoup sont générés par l'IA, même si certains reposent aussi sur des analyses manuelles sérieuses et de haut niveau
- Avec cette hausse des signalements, rsync a désormais besoin d'une suite de tests plus approfondie, d'analyses de couverture de code, de tests CI sur davantage de plateformes, de scans intentionnels des problèmes de sécurité et de techniques de défense en profondeur
- Le mainteneur est à la retraite et aimerait passer plus de temps à naviguer, mais face à l'ampleur du travail nécessaire, il a utilisé plusieurs outils d'IA et ne regrette pas ce choix
Suite de tests Python et travail assisté par l'IA
- L'ancienne suite de tests de rsync, basée sur des scripts shell, a été réécrite en Python, avec une architecture dans laquelle la conception centrale et le plan de validation restent directement pris en charge par le mainteneur
- Claude a été utilisé pour les tâches répétitives, tandis que Codex et Gemini ont servi à la vérification croisée ; il ne s'agissait pas simplement de déléguer la consigne « convertir la suite de tests en Python »
- Le mainteneur a revu personnellement chaque partie, y a consacré beaucoup de temps de CI pour l'ajustement, puis a déplacé l'exécution de la majorité des tests vers plusieurs VM locales afin de réduire les temps d'attente de la CI
- La mention
co-authored by claude dans l'historique des commits ne reflète, selon lui, qu'une petite partie de l'ensemble du travail d'ingénierie logicielle réalisé
Débat sur les LLM, choix de pytest, régressions de 3.4.3
- Le fait de connaître le mode de fonctionnement des LLM n'en fait pas des outils inutiles ; ils doivent être utilisés avec précaution, mais sont considérés comme utiles dans l'environnement actuel de l'ingénierie logicielle et de la maintenance en sécurité informatique
- rsync 3.4.3 était une release volontairement orientée vers la correction des problèmes de sécurité, et certains cas d'usage valides mais atypiques ont été affectés par ces changements
- Les cas d'usage touchés n'étaient couverts ni par la suite de tests rsync existante ni par les tests manuels, et les régressions signalées via les issues et PR du dépôt GitHub sont en cours de traitement une à une
- pytest est beaucoup utilisé dans d'autres projets, mais certains besoins de la suite de tests rsync ont été jugés très difficiles à satisfaire avec pytest, d'où le choix de concevoir une approche de test distincte
Prochaine release et extension des tests de sécurité
- Les rapports de sécurité continuent d'arriver, et plusieurs travaux liés à des CVE sont actuellement en cours
- D'autres développeurs dotés de compétences en développement système et en sécurité ont rejoint l'effort, certains s'étant fait remarquer à la faveur de la colère récente
- Le prochain choix se situe entre une 3.4.4 atténuant certaines régressions et une 3.5.0 embarquant des changements bien plus importants ; la 3.5 élèvera fortement le niveau de sécurité de rsync, mais ce sera une release de grande ampleur
- Pour appliquer rapidement un ensemble important de changements, un logiciel comme rsync avait besoin d'une suite de tests complète, et la réécriture de la nouvelle suite de tests est née de cette nécessité
- La release 3.5 intégrera des tests supplémentaires consacrés aux problèmes de sécurité
Comparaison avec openrsync et demande de revue de code
- À ceux qui envisagent de packager openrsync pour certaines plateformes, la réponse est qu'il est possible d'appliquer la nouvelle suite de tests rsync à openrsync
- Voici l'exemple de commande
./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp
- openrsync échoue actuellement à 85 des 98 tests ; beaucoup de ces échecs sont dus à des fonctionnalités absentes d'openrsync, mais cela ne constitue pas un bon résultat
- Plutôt que d'exprimer davantage de colère, il est demandé de relire réellement le code publié et de formuler des critiques constructives
1 commentaires
Avis sur Lobste.rs
À en juger par la citation, on a l’impression que l’auteur veut partir naviguer mais ressent malgré tout une pression liée à la maintenance du projet, et qu’il a cru voir dans l’usage des LLM une solution pour concilier les deux
C’est très bien de prendre sa retraite et de profiter de la voile sans corriger les bugs, et c’est très bien aussi de ne pas corriger les bugs d’un projet open source. Il suffit simplement de le dire publiquement et en toute transparence. Comme on disait autrefois, « patches welcome » suffit. C’est d’autant plus vrai si des entreprises disposant de nombreuses ressources dépendent de ce projet
J’aimerais que davantage de mainteneurs et de développeurs puissent profiter de leur retraite et de la voile sans subir la pression de devoir recourir à « l’aide » des LLM pour assurer la maintenance de l’open source. Cela dit, s’il veut expérimenter les LLM sur le projet rsync, c’est son choix. Même si d’autres, moi y compris, ne sont pas d’accord
Quelle qu’en soit la raison, ceux qui harcèlent les développeurs open source semblent oublier que les logiciels open source gratuits ne sont pas des produits, mais des cadeaux
Ceux qui restent à l’extérieur à regarder peuvent forker si ça ne leur plaît pas. Andrew peut travailler sur ce projet comme il l’entend, et nos commentaires comme nos avis ne lui sont pas indispensables
Le point encourageant, c’est qu’à long terme quelqu’un d’autre pourrait peut-être reprendre la maintenance de rsync. Tridge l’a déjà transmise à un nouveau mainteneur par le passé
J’ai assisté à une présentation sur des cas où l’OpenJS Foundation a fourni du financement et un accompagnement à la transition pour certains projets, afin de passer d’un maintien par une seule personne à une maintenance en équipe, et j’ai écrit un article pour LWN à ce sujet, qui doit être publié aujourd’hui. Des projets comme rsync ont besoin de ce type de soutien en bien plus grande quantité
Les problèmes de sécurité impliquent une forte pression, une grande exposition, et sont souvent éloignés du cœur même du projet qui intéresse le mainteneur
La maintenance comporte beaucoup de responsabilités et tout n’est pas plaisant, mais j’éprouve de la gratitude envers les mainteneurs de logiciels libres et open source quand ils prennent aussi en charge ce genre de travail. Il ne semble pas y en avoir beaucoup qui le fassent
On peut juger que le coût pour atteindre un objectif donné est trop élevé sans l’aide des LLM, alors qu’avec leur aide il devient raisonnable
Vu de manière positive, cela signifie qu’un mainteneur open source cherchant à préserver un bon équilibre vie professionnelle-vie personnelle peut réduire sa charge de travail grâce aux LLM tout en atteignant plus facilement les objectifs qu’il souhaite
Le passage cité n’est qu’une partie de l’introduction, et ce texte a clairement été écrit avec prudence et nuance, ce n’est pas un simple billet de base sur la maintenance open source
Plus étrange encore, le contexte situé juste avant la citation a été omis. Il y est expliqué qu’avec l’explosion du nombre de signalements, il a fallu considérablement renforcer les défenses de rsync, avec une suite de tests bien plus rigoureuse, une analyse de couverture du code, des tests CI sur davantage de plateformes, la recherche de problèmes de sécurité et l’ajout de techniques de défense en profondeur
Dans ce cas précis, l’auteur est à la retraite, mais dans d’autres projets open source, des personnes ayant un emploi ou d’autres obligations peuvent elles aussi être emportées par une hausse de la charge de travail similaire. Honnêtement, je suis déconcerté de voir ce commentaire autant recommandé, et il ne me semble pas avoir été écrit de bonne foi. Cela ressemble au mieux à une réaction paresseuse, à peine plus soignée qu’un commentaire posté en vitesse après avoir seulement lu le titre
Je n’ai pas l’intention d’excuser ou d’approuver le harcèlement, mais il manque quelque chose dans cette défense
L’explication donnée est que l’auteur a conçu l’architecture pour le vibe coding, a relu le code produit, maîtrise le code comme les chatbots, a abordé le vibe coding avec prudence et a essayé de trouver un équilibre entre sécurité et régressions fonctionnelles. Cela paraît plausible, mais en pratique il y a bien eu des régressions, et l’auteur ne parvient même pas à en identifier la cause
Il dit avoir confié « les tâches simples à des outils d’IA parce qu’ils y excellent », mais ce n’est pas le cas. Les chatbots sont en réalité mauvais pour écrire du code. C’est le point essentiel, et l’auteur semble ne même pas s’en rendre compte
Ce serait bien de vérifier si les chiffres ont réellement augmenté récemment. Les régressions en elles-mêmes ne sont pas rares, et il est possible que des gens cherchent simplement un prétexte pour attaquer Andrew
L’auteur reconnaît qu’il y a eu des régressions dans certains cas d’usage de la release rsync 3.4.3, et explique que, pour cette release, il a délibérément donné davantage de poids à la correction des problèmes de sécurité, ce qui a affecté certains cas d’usage valides mais inhabituels
Ces cas n’étaient pas couverts par la suite de tests existante de rsync ni par les tests manuels qu’il avait lui-même effectués, il est en train de traiter ces régressions et remercie les personnes qui les ont signalées via des issues ou des PR dans le dépôt GitHub. Il présente aussi ses excuses si votre cas d’usage a été touché, et ajoute que, si vous êtes prêt à assumer le risque de sécurité, vous pouvez utiliser une release précédente à la place
« Le monde du génie logiciel a radicalement changé ces derniers mois », « le monde de la maintenance logicielle, au milieu de la sécurité IT et de l’avalanche de signalements, a complètement changé ces dernières semaines » : j’entends cette rengaine en boucle depuis environ six mois, et ça fatigue.
Si cette avalanche de signalements est causée par les LLM, chercher la solution dans les LLM me paraît une direction incroyablement erronée.
Cela dit, je crois sans peine qu’entretenir quelque chose de populaire aujourd’hui doit être horrible. Peut-être que, pour lui, le mieux serait simplement de se retirer et de profiter d’une vraie retraite, plutôt que d’essorer encore davantage un temps de calcul limité.
Si c’était un outil ne serait-ce qu’à moitié aussi utile que ce que les gens prétendent, son utilité parlerait d’elle-même.
Cela dit, un témoignage venant de quelqu’un comme Tridgell vaut la peine d’être écouté. Et le « déluge » de rapports de sécurité doit être pris au sérieux. Peu importe qui les a trouvés ou quoi les a trouvés, un problème de sécurité reste un problème de sécurité. C’est pour ça que ce texte ne ressemble pas aux offensives lassantes qu’on voit d’habitude.
Au final, on pourrait entrer dans une spirale descendante de dépendance croissante aux LLM.
En quoi est-ce une mauvaise direction ? Tu veux dire qu’on serait mieux sans LLM du tout ?
Le développement assisté par LLM ne produit pas forcément des « résultats pourris ».
Je suis reconnaissant que ce texte ait été écrit et partagé. J’ai notamment remarqué le passage où il hésite entre atténuer certaines régressions avec la 3.4.4 ou passer à la 3.5.0, qui embarque des changements bien plus importants.
Si l’auteur lit ceci, 3.4.4 me semble être la bonne approche ici. Après une régression dans la dernière release, enchaîner directement avec une grosse 3.5.0 paraîtra téméraire à beaucoup de monde. Si on aide les gens à mieux comprendre la différence, cela réduira les inquiétudes.
Quant au passage où il dit qu’il voulait d’abord travailler publiquement sur master sur la structure centrale de la nouvelle suite de tests, mais qu’au vu de la colère suscitée ce n’était peut-être pas une bonne idée, je ne pense pas qu’une moindre transparence améliorerait la perception ni les réactions. Au mieux, cela ne ferait que repousser une opposition plus forte.
Dire à openrsync d’exécuter la nouvelle suite de tests rsync n’est pas équitable. samba rsync est au protocole 32, tandis qu’openrsync est au protocole 27, et il ne prétend de toute façon pas à une complétude fonctionnelle.
Medium et Cloudflare, quelle combinaison atroce, deux choses qui ne devraient pas être mélangées.
https://archive.is/qbyVA
La maintenance open source est un travail ingrat. Tridge a essayé de corriger la dette technique de la suite de tests et de répondre de façon responsable au flot de CVE détectées par les LLM, mais il semble avoir pris de plein fouet la loi de Hyrum. Le plan 3.4.4 est probablement le moins mauvais choix, et il va sans doute falloir aller de l’avant.
Je suis partagé sur cette question. D’un côté, j’ai tendance à penser que la sécurité ne peut être garantie que lorsque des humains écrivent directement le code
parce qu’ils réfléchissent au code pendant qu’ils l’écrivent et détectent les erreurs plus tôt. J’écris bien mieux quand je code moi-même que lorsque je relis. En relecture, comme je n’ai pas réfléchi attentivement à chaque ligne, beaucoup de choses passent simplement au travers
D’un autre côté, indépendamment du fait fondamental que le harcèlement est inacceptable, Andrew a le droit de gérer son projet sur son temps libre comme il l’entend. S’il veut utiliser des LLM, je ne suis pas d’accord, mais c’est son projet et cela relève de son appréciation. Si cela ne vous convient pas, il faut migrer mes sauvegardes vers restic ou borgbackup, ou fork rsync
Pour être clair, je ne suis pas opposé au vibe coding en soi. On m’en fait utiliser au travail de manière à moitié forcée, et pour écrire le code glue ennuyeux et peu original qui constitue l’essentiel de mon travail ces temps-ci, c’est passable. En revanche, je n’en utilise pas sur mon temps libre
rsyncn’est de toute façon pas non plus une solution particulièrement adaptéecar il n’aide pas à restaurer lorsque le contenu d’un fichier a été corrompu. Un outil comme restic est bien meilleur et conserve aussi les versions précédentes des fichiers pour traiter ce type de cas. Il suit même les suppressions, ce qui permet de savoir quels fichiers ne sont plus pertinents
J’ai de l’expérience en sécurité applicative, je peux repérer certains exploits et j’arrive aussi à en identifier en revue. Mais je ne suis tout simplement pas aussi efficace que les meilleurs LLM actuels quand il s’agit de boucler sur « trouve des cas plus pathologiques »
J’ai trouvé dans des logiciels aussi populaires des problèmes dans mon code, dans les bibliothèques utilisées et dans des implémentations alternatives, sans effort particulier. Le temps et l’acharnement qu’un humain peut y consacrer ne sont tout simplement pas comparables
À l’échelle d’une organisation, il existe tout un déploiement de logiciels de sécurité pour prévenir, détecter et traiter les incidents. Dans chaque domaine, il y a toujours des angles morts et davantage à faire. Une organisation peut préférer accepter une amélioration de sa posture de sécurité, même en sachant qu’elle ne sera pas parfaite, plutôt que de n’avoir aucune amélioration du tout. Le compromis apporté par les LLM en fait partie
Ce point d’équilibre dépend du contexte, mais il est rare qu’il revienne à dire « tout le code doit être écrit à la main »
Cela vaut aussi pour des serveurs comme rsync. Comme le dit l’auteur, il peut être nécessaire de procéder à un gros refactoring pour le rendre plus robuste et plus résilient. Si un LLM peut aider à refactorer vers une séparation des privilèges afin d’obtenir un code de confiance plus réduit, on peut alors accepter certains bugs en dehors de ce périmètre
Je ne connais pas le contexte précis de rsync, mais j’ai tendance à croire que, dans les limites de ressources généralement très restreintes de ce type de projets, l’auteur prend les meilleures décisions possibles pour le projet et ses utilisateurs
En contrepartie, rclone dispose de parallélisme, ce qui lui permet d’utiliser bien plus efficacement la bande passante réseau disponible
Cela donne une borne supérieure aux problèmes possibles
La borne inférieure, ce sont les bugs et vulnérabilités que je peux trouver, que d’autres peuvent trouver, ou que quelque chose d’autre — par exemple un LLM — peut trouver
La situation où une personne relit du code C qu’elle a elle-même écrit, comme rsync, est difficile à qualifier de bonne position dans cet espace. Je ne cherche absolument pas à blâmer Andrew
J’éprouve de la sympathie pour un mainteneur retraité qui veut partir naviguer, mais je ne pense pas que ce contexte change quoi que ce soit au fond
Tridgell ne nous doit aucun travail et il est libre de prendre sa retraite pour aller naviguer. Si c’est ce qu’il veut faire, je lui souhaite le meilleur. Je comprends son sens des responsabilités, mais si j’ai bien lu entre les lignes, il semble aussi en ressentir le poids dans une certaine mesure
Mais rsync est un logiciel essentiel, et je pense que quiconque entreprend de le maintenir doit respecter un certain niveau de qualité. Si le travail du mainteneur n’atteint pas ce niveau, c’est une erreur. Cela ne justifie en rien le harcèlement. Dire qu’une chose est une erreur ne signifie pas que la personne qui l’a commise est mauvaise, ni qu’on manque d’empathie envers elle
La question est donc de savoir si le travail réalisé avec des outils de codage IA était à la hauteur du standard. Et ce standard est, en gros, le suivant : « vaut-il mieux que ce travail existe, même à cette qualité, plutôt qu’il n’existe pas du tout ? » Si cela améliore le logiciel, il faut continuer ; si cela le dégrade, il faut arrêter. Je ne prétends pas que ce soit une définition brillante, mais je pense que c’est la bonne
Nous n’avons pas le droit d’exiger du travail supplémentaire de Tridgell, mais il y a malgré tout place pour dire, si c’est le cas, « cela détériore la situation pour les utilisateurs »
Honnêtement, je n’ai pas encore une opinion totalement arrêtée sur la manière de juger ce travail. Il y a eu une régression, et Tridgell l’a présentée comme un cas limite, mais sans davantage de contexte je ne sais pas comment comparer l’impact de cette régression dans un cas limite à la valeur de la correction d’un problème de sécurité potentiel
Certains penseront peut-être à « WITHOUT ANY WARRANTY », mais cette clause n’a rien à voir ici. C’est une exclusion de responsabilité juridique, pas un renoncement à la fierté du travail bien fait ni à l’exigence non juridique de faire de son mieux. Ce commentaire aussi est fourni « WITHOUT ANY WARRANTY », mais si je me trompe, il est évidemment normal que je sois critiqué
Ce n’est pas l’auteur qui en a fait un logiciel essentiel. Si vous ou quelqu’un d’autre l’utilisez, la responsabilité incombe à l’utilisateur. Si le logiciel ne fonctionne pas comme attendu, il faut le forker ou le remplacer. Ce qu’on ne peut pas faire, c’est forcer cette personne à agir selon vos exigences
Pour le contexte, à destination de ceux qui ont raté le signalement de la régression : https://github.com/RsyncProject/rsync/issues/929
Le signalement du problème est une capture d’écran d’un post Mastodon, suivie depuis de plus de 300 commentaires de dispute
Pas besoin d’expliquer, il suffit de continuer à faire comme d’habitude. Ceux qui n’aiment pas ça continueront à ne pas aimer
Les gens ont commencé à détester ça dès qu’ils ont cessé d’écrire en assembleur, et ça ne s’arrêtera pas