The Rsync Situation Has Gone Too Far

SYNTHÈSE STRUCTURÉE

Le retour d’Andrew Tridgell et l’arrivée de Claude

Depuis mars 2025, Andrew Tridgell (Tridge), auteur original de rsync, a repris la maintenance du projet après des années de stagnation. L’analyse des commits montre qu’avant cette date, le développement était quasi inexistant, avec de longues périodes sans activité. Après mars, la majorité des patches sont co-écrits avec Claude Opus 4.6. L’intervenant précise : « It’s unclear exactly to what extent Tridge is actually making use of Claude, but again, referring back to the graph, considering the work has massively increased ever since its inclusion, I think it’s fair to say he is using it relatively actively. »

La nature des changements : surtout des tests et de la CI

Une part importante des modifications ne concerne pas le code général de rsync, mais la réécriture de la suite de tests en Python et l’infrastructure CI. L’intervenant note que Claude a généré un framework de tests contenant « tests that literally cannot fail ». Cela relativise l’impact direct sur les fonctionnalités principales, même si cela introduit des problèmes de qualité.

Les regressions réelles dans rsync 3.4.3

Plusieurs bugs ont été signalés après la sortie de la version 3.4.3, dont certains sont directement attribuables aux commits co-écrits par Claude :

Problème de compilation sur Darwin ancien (commit 30656c5)
Erreur « invalid argument 22 » sur toutes les lectures de fichiers avec le protocole natif
Fichier openat.h introuvable sous Linux
Problème de sécurité cassant --link-dest via le démon rsync
Échec de compilation de syscall.c sur Linux 5.10 (symbole openat2 manquant)
Refus des chemins sources absolus commençant par /

Attention à ne pas tout attribuer à l’IA

L’intervenant met en garde contre une généralisation abusive : « some of these are not actually that. It’s just now there is a lot more eyes on rsync and there’s a lot more people trying to find issues. » Il montre qu’un bug sur nsec a pu être reproduit sur rsync 3.2.7, bien avant l’arrivée de Claude. Un autre rapport concernait en réalité rclone, un projet différent. Certains signalements n’ont même pas de commit identifié ni de condition de reproduction.

La réaction explosive sur GitHub et Hacker News

Le déclencheur a été un post Mastodon signalant une régression après la mise à jour vers 3.4.3, avec la mention « 36 commits by Tridge and Claude ». Cela a généré une discussion sur Hacker News devenue « an absolute hellscape of nothing productive being discussed ». Le thread GitHub contient des commentaires agressifs, des memes, et même une image violente (non montrée). L’intervenant qualifie la situation de « Reddit thread » plutôt que d’issue tracker sérieux.

La réponse mesurée de Tridge

Tridge n’a répondu qu’une seule fois dans le thread : « In case anyone doesn’t know, the issue is fixed in master here 887. There will be a new release soon. I’m just dealing with a pile of other issues first. All patches are reviewed by humans. We have three people on the Rsync security team now. » L’intervenant approuve cette approche : « Don’t spend all day sitting around replying to people. Because a lot of the people in this thread, they don’t develop Rsync. They don’t, in some cases, even use Rsync. »

Le contexte de maintenance : un projet en souffrance

L’intervenant rappelle que Tridge est revenu parce que le mainteneur précédent avait quitté, et que le projet manquait cruellement de contributeurs. Il cite l’annonce officielle : « various life events have been monopolizing my time. I reached out to Tridge, Andrew Tridgell, the original author, and he has graciously agreed to get back into rsync work. » Depuis, Tridge est essentiellement seul, avec quelques rares contributions externes. L’intervenant conclut : « Tridge is basically by himself at this point in rsync and he doesn’t have the time to maintain it. »

Les forks et alternatives : une solution théorique

Plusieurs commentaires suggèrent de forker rsync. L’intervenant rappelle que des alternatives existent (comme openrsync dans le monde BSD), mais qu’elles souffrent des mêmes problèmes de maintenance : « they basically just have one guy doing everything. So if that one guy steps away, um, good luck. » Il invite ceux qui critiquent à contribuer concrètement plutôt que de se contenter de commenter.

L’avis de Sam James (découvreur de XZ)

Sam James, connu pour avoir trouvé la backdoor XZ, apporte une perspective nuancée : « the regressions aren’t new with it. It does something hard, it has to deal with symlinks, releases have often had regressions for a long time, especially for security fixes, and it long predates LLMs because symlinks are hard. » Il ajoute que voir « a gazillion clawed commits still makes me uncomfortable », mais insiste sur l’importance de distinguer ce qui est nouveau.

CONCEPTS CLÉS

Vibe coding : Terme péjoratif désignant l’écriture de code par IA sans compréhension réelle, utilisé par les détracteurs pour qualifier les commits de Tridge.
Regression : Bug introduit par une modification qui casse un comportement qui fonctionnait auparavant. Certaines sont réelles, d’autres sont des bugs anciens redécouverts.
Openat2 : Appel système Linux pour ouvrir des fichiers avec des restrictions de chemin, dont l’absence dans certains noyaux (5.10) a causé une erreur de compilation.
CI pipeline : Infrastructure d’intégration continue, cible principale des commits co-écrits par Claude (tests, automatisation).

CONCLUSION

La controverse autour de rsync illustre un problème structurel des logiciels open source vieillissants : un mainteneur unique, débordé, qui se tourne vers l’IA pour accélérer le travail, au prix de regressions réelles mais limitées. La réaction communautaire, disproportionnée et souvent mal informée, pollue les canaux de signalement de bugs et ne résout rien. Le message principal est double : d’une part, il faut évaluer les regressions avec rigueur (reproduction, identification du commit) plutôt que de tout attribuer à l’IA ; d’autre part, si l’on veut un rsync sans IA, il faut contribuer au projet, pas seulement critiquer. Comme le dit l’intervenant : « If you don’t like the inclusion of the AI code, if you want to fork the project, if you want to help out, do it. Actually do it. »