Rsync 3.4.3 corrige 6 failles mais casse des sauvegardes, l’IA dans le code met les admins en colère

Rsync vient de publier sa version 3.4.3 et, au lieu du soulagement habituel après un correctif de sécurité, une partie des utilisateurs a vu un truc bien plus angoissant, des sauvegardes incrémentales qui se comportent mal juste après la mise à jour. Quand ton outil de copie fiable depuis les années 90 se met à surprendre, tu ne te dis pas “on verra demain”, tu bloques le déploiement et tu fouilles.

Le détail qui met le feu aux poudres, c’est que depuis la version 3.4.1, des dizaines de modifications sont signées “tridge and claude“, c’est-à-dire Andrew Tridgell, figure historique du projet, et Claude, l’assistant IA d’Anthropic. Le débat ne porte pas seulement sur l’ego ou la philosophie, il touche un point très concret, la confiance dans une brique d’infrastructure utilisée pour des backups, des miroirs, des déploiements, parfois dans des chaînes d’astreinte où la moindre régression coûte cher.

Rsync 3.4.3 vise 6 CVE, les régressions arrivent vite

La sortie de Rsync 3.4.3 a été présentée comme une mise à jour de sécurité, publiée le 20 mai, avec la correction de six vulnérabilités référencées en CVE et affectant rsync 3.4.2 et antérieur. Sur le papier, c’est le genre de version que tu veux déployer rapidement, surtout si rsync est exposé via un daemon, ou intégré à des flux de synchronisation réguliers.

Le souci, c’est que des utilisateurs ont signalé quasi immédiatement des régressions. Les retours mentionnent des workflows touchés en mode daemon, et des transferts incrémentaux qui ne donnent plus le résultat attendu après la mise à jour. Dans l’univers des sauvegardes, “ça marche la plupart du temps” n’existe pas, une anomalie suffit à rendre l’outil suspect, parce qu’elle peut rester invisible jusqu’au jour où tu dois restaurer.

Un point technique revient dans les discussions, des correctifs liés à des configurations de daemon utilisant chroot = no. Cette option, qui peut exister dans des installations réelles, se retrouve au centre de certains cas problématiques rapportés après 3.4.3. Dit autrement, la version arrive avec des changements de sécurité, mais elle modifie aussi des comportements que des admins considéraient comme stables.

Le résultat, tu le vois dans les réactions, des équipes préfèrent revenir à une version antérieure plutôt que d’encaisser l’incertitude. Certains messages résument la stratégie en une phrase, “revenir à 3.4.1“. Ce n’est pas un caprice, c’est une gestion du risque, tu acceptes parfois une version moins récente si elle est connue, documentée, et surtout prévisible dans tes scripts et tes restaurations.

Les commits “tridge and claude” relancent la question de la confiance

Ce qui change l’ambiance, c’est la trace laissée dans l’historique, depuis 3.4.1, des commits signés “tridge and claude“. Dans un projet où beaucoup d’utilisateurs ne demandent pas de nouveautés, mais de la stabilité, la mention explicite d’une assistance IA agit comme un révélateur. Même si la régression n’est pas “causée” mécaniquement par l’IA, l’association devient immédiate dans l’esprit de nombreux admins.

Un commentaire récurrent dans ce type d’affaire, c’est l’idée que rsync est “fini”, au sens où il n’a pas besoin d’une avalanche de changements pour rester utile. C’est une vision répandue pour des outils d’infrastructure, la valeur vient de la répétabilité, pas d’une course aux features. Quand tu ajoutes une couche d’incertitude, même perçue, tu touches le contrat implicite entre mainteneurs et utilisateurs.

Le débat s’élargit aussi à un autre phénomène, les mainteneurs expliquent recevoir un volume important de rapports de sécurité, dont une partie générée par IA. Là, tu as une boucle, de l’IA produit du bruit, les mainteneurs se défendent parfois avec de l’IA, et au milieu tu as des utilisateurs qui veulent juste que leur sauvegarde soit fiable. Le problème n’est pas seulement “IA ou pas IA”, c’est la pression et la charge de tri.

Dans les réactions, on voit aussi une nuance importante, certaines personnes disent ne pas être opposées à l’IA, mais exigent de la revue, des tests, de la validation, puis encore de la revue. Cette position est moins spectaculaire qu’un rejet total, mais elle est plus utile, parce qu’elle pointe le vrai nerf de la guerre, le processus. Si tu modifies un outil critique, tu dois prouver que tu n’as pas cassé des cas d’usage réels, pas seulement compiler et passer deux tests unitaires.

Andrew Tridgell évoque une 3.4.4 ou une 3.5, les utilisateurs tranchent

Face à la controverse, Andrew Tridgell a pris la parole pour répondre aux critiques et reconnaître le sujet des régressions. Il explique travailler à les traiter et envisage deux options, une version 3.4.4 pour corriger une partie des problèmes, ou continuer vers une 3.5 prévue avec des changements de sécurité plus étendus. Pour les utilisateurs, cette hésitation est compréhensible, mais elle laisse une fenêtre d’incertitude opérationnelle.

Dans la vraie vie, quand tu es admin, tu ne peux pas attendre tranquillement que la feuille de route se stabilise. Tu as des cron, des jobs, des pipelines, des sauvegardes nocturnes, des rotations, des fenêtres de maintenance. Donc le réflexe, c’est le gel, tu bloques la montée de version, tu épingles un paquet, ou tu reviens en arrière si tu as déjà déployé. Ce n’est pas élégant, mais c’est rationnel.

On voit aussi, dans des échanges communautaires, des utilisateurs qui se félicitent d’être sur des distributions qui privilégient la stabilité. L’exemple le plus parlant dans les discussions, c’est un utilisateur de Linux Mint qui indique tourner en 3.2.7, pendant qu’un autre mentionne un environnement de test en 3.4.3 avec un “ruh-roh” très explicite. Ce contraste illustre un truc simple, les politiques de packaging peuvent amortir ou accélérer les crises.

Le point délicat, c’est que la mise à jour 3.4.3 est aussi une mise à jour de sécurité. Revenir en arrière, c’est potentiellement renoncer à des corrections de vulnérabilités, même si certaines exigent des configurations non par défaut. Tu te retrouves donc à arbitrer entre deux risques, la faille théorique et la régression concrète. Et dans beaucoup d’équipes, une régression qui menace la restauration pèse plus lourd, parce qu’elle touche directement la continuité d’activité.

Pourquoi une régression rsync peut coûter cher en production

Rsync n’est pas juste un outil de copie, c’est une brique qui se cache derrière des scripts de sauvegarde, des synchronisations inter-sites, des déploiements, des miroirs de dépôts, des migrations. Quand une régression touche l’incrémental ou le mode daemon, ça peut impacter des chaînes entières sans que personne ne s’en rende compte tout de suite, parce que le job “termine”, mais le résultat n’est plus celui attendu.

Un exemple classique, une entreprise fait une sauvegarde incrémentale toutes les heures et une complète le week-end. Si l’incrémental se met à ignorer un cas, à mal interpréter une option, ou à changer un comportement, tu peux accumuler des jours de sauvegardes “vertes” mais inexploitables. Le jour où tu dois restaurer, tu découvres le problème trop tard. C’est pour ça que les admins réagissent fort, la gravité n’est pas l’erreur visible, c’est l’erreur silencieuse.

Autre cas, les hébergeurs et équipes infra utilisent rsync pour pousser des releases ou synchroniser des arborescences. Une régression peut provoquer des transferts plus lourds, des temps de job qui explosent, des fenêtres de maintenance dépassées, ou des pics de charge réseau. Même sans chiffres publics précis, l’effet domino est connu, un changement de comportement dans un outil massivement scripté se propage vite, parce que tout le monde réutilise les mêmes recettes.

Il y a aussi un aspect humain, la confiance. Quand un outil a une réputation “béton” depuis des années, il devient un réflexe. Le jour où il surprend, tu perds du temps en vérifications, tu ajoutes des garde-fous, tu multiplies les tests de restauration, tu mets des alertes. C’est sain, mais ça a un coût. Et c’est là que la polémique sur l’IA prend, elle symbolise pour certains une nouvelle source de variabilité dans un domaine où l’on cherche l’inverse.

Open source et IA, la polémique rsync rappelle un problème de méthode

Le fond du débat, c’est moins “l’IA est-elle autorisée” que “quel niveau d’exigence impose-t-on quand on touche à un outil critique”. Les mainteneurs expliquent aussi subir une hausse des signalements de sécurité générés par IA, ce qui crée un bruit difficile à trier. Quand tu reçois des rapports en masse, tu risques de passer plus de temps à filtrer qu’à corriger, et tu peux être tenté d’accélérer avec des outils automatiques.

Le problème, c’est que l’automatisation peut déplacer le risque. Si des contributions assistées par IA arrivent plus vite que la capacité de revue, tu augmentes la probabilité de régressions. Dans le cas présent, la présence de commits “Claude” rend ce sujet visible, mais la question existe même sans IA, une vague de changements non suffisamment testés peut casser des workflows. L’IA sert de catalyseur, parce qu’elle cristallise la peur du “code non compris”.

Des utilisateurs évoquent déjà des migrations vers des alternatives, avec un nom qui revient, openrsync. Rien ne dit que tout le monde va basculer, mais le simple fait que l’idée circule est un signal. Les outils d’infrastructure vivent sur la confiance collective. Une fois que certains acteurs, distributions, admins, équipes SRE, commencent à dire “on ne peut plus faire confiance”, l’adoption peut se fissurer, même si les bugs sont corrigés ensuite.

Il faut aussi garder une nuance, la colère est compréhensible, mais la situation montre la difficulté de maintenir un projet open source très utilisé, avec une pression sécurité croissante. On peut critiquer un manque de tests ou une communication maladroite, mais il faut aussi regarder le système, la dépendance de milliers d’organisations à des projets maintenus par peu de personnes. Tant que ce déséquilibre reste, chaque incident de ce type risque de se reproduire, avec ou sans IA.