rsync remplacé par openrsync dans macOS Sequoia

 (derflounder.wordpress.com)
2 points par GN⁺ 2025-04-07 | 1 commentaires | Partager sur WhatsApp
  • Alors que l’outil de synchronisation de fichiers intégré à macOS reposait encore sur une base datant de 2006, Apple a remplacé rsync 2.6.9 par openrsync
  • L’ancien rsync de macOS avait reçu les correctifs nécessaires pour la sécurité et d’autres problèmes, mais n’intégrait pas les fonctionnalités de rsync 3.x apparues après la 2.6.9
  • La principale raison de ce changement tient à la différence de licence : rsync 2.x est distribué sous GPLv2, tandis que rsync 3.x l’est sous GPLv3
  • openrsync est compatible avec rsync, mais ne prend en charge qu’une partie des arguments de ligne de commande ; des scripts existants peuvent donc ne pas fonctionner tels quels sur Sequoia
  • À partir de macOS 15.4, /usr/bin/rsync pointe vers openrsync ; les administrateurs Mac doivent donc vérifier les options prises en charge et la compatibilité de leurs automatisations existantes

rsync 2.6.9, longtemps resté dans macOS

  • rsync est un outil en ligne de commande qui permet de transférer et de synchroniser des fichiers sur les systèmes d’exploitation de type Unix
    • Il peut être utilisé entre des périphériques de stockage directement connectés au même ordinateur
    • Il peut aussi servir à synchroniser des fichiers avec un autre ordinateur sur le réseau
  • macOS a longtemps inclus rsync, mais la version fournie par Apple était rsync 2.6.9, la dernière version de rsync 2.x
  • rsync 2.6.9 est sortie en novembre 2006, et Apple n’a pas fait évoluer le rsync de macOS vers une version ultérieure, même après la sortie de rsync 3.x
  • Apple a bien fourni les mises à jour nécessaires pour les problèmes de sécurité et d’autres problèmes concernant rsync 2.6.9 inclus dans macOS
  • Mais jusqu’à macOS Sequoia, le rsync d’Apple reposait sur une base vieille de près de 20 ans et n’incluait pas les nouvelles fonctionnalités ajoutées dans les versions de rsync postérieures à la 2.6.9

Une stagnation due à GPLv2 et GPLv3

  • rsync 2.x et 3.x sont distribués sous des versions différentes de la licence GPL
  • Apple estimait pouvoir respecter les conditions GPLv2 de rsync 2.x, mais pas celles de la GPLv3 de rsync 3.x
  • C’est pourquoi rsync 3.x n’a pas été fourni dans macOS

Le passage à openrsync dans macOS Sequoia

  • Dans macOS Sequoia, Apple a remplacé rsync 2.6.9 par openrsync
  • openrsync est une implémentation de rsync qui n’utilise pas de licence GPL
  • openrsync est distribué sous ISC license, l’une des licences de type BSD
  • ISC license est une licence permissive qui impose des restrictions minimales sur l’utilisation, la modification et la distribution du logiciel concerné
  • Apple a estimé pouvoir respecter les conditions de licence d’openrsync, contrairement aux conditions GPLv3 de rsync 3.x

Des différences de compatibilité importantes pour les administrateurs Mac

  • Apple pourra désormais fournir des versions mises à jour d’openrsync sans se préoccuper des problèmes de conformité à la GPL liés à rsync
  • Le changement pratique le plus important est qu’openrsync, bien qu’il soit compatible avec rsync, n’accepte qu’une partie des arguments de ligne de commande de rsync
  • Des fonctionnalités de rsync qui fonctionnaient sur les anciennes versions de macOS peuvent échouer sur macOS Sequoia
    • Cela peut s’expliquer par le fait que ces fonctionnalités ne sont pas présentes dans l’outil en ligne de commande openrsync inclus dans Sequoia
  • Les fonctionnalités prises en charge par openrsync dans macOS Sequoia peuvent être consultées dans la page de manuel d’openrsync

Comment vérifier dans macOS 15.4

  • À partir de macOS 15.4, l’outil openrsync est relié à /usr/bin/rsync
  • Les utilisateurs peuvent exécuter openrsync comme ils exécutaient auparavant l’outil en ligne de commande rsync
  • Les informations de version d’openrsync se vérifient avec la commande suivante
/usr/bin/rsync --version
  • La sortie ressemble à ceci
username@computername ~ % /usr/bin/rsync --version
openrsync: protocol version 29
rsync version 2.6.9 compatible
username@computername ~ %
  • La sortie affiche protocol version 29 et rsync version 2.6.9 compatible

À lire aussi

1 commentaires

 
GN⁺ 2025-04-07
Avis sur Hacker News

  • La documentation d’openrsync est beaucoup trop pauvre, ce qui n’inspire pas confiance quant à sa capacité à remplacer rsync
    Pour un programme de copie de fichiers, il faut pouvoir faire une copie complète sans perdre un seul bit des données ni des métadonnées de l’original ; sinon, je considère que c’est inutilisable
    Beaucoup d’outils de copie/d’archivage de type Unix ne font pas de copie complète avec leurs options par défaut, et certains ne le peuvent pas, quelles que soient les options utilisées
    Jusqu’à il y a quelques années au moins, scp avait aussi du mal à effectuer une copie complète lorsque le système d’exploitation ou le système de fichiers différait ; je ne l’utilisais donc pas, et je me suis toujours servi uniquement de rsync par-dessus ssh
    rsync est l’un des rares outils qui, avec les bonnes options, préserve même les attributs étendus, les ACL et les timestamps haute précision entre des systèmes d’exploitation/systèmes de fichiers différents, comme entre FreeBSD UFS et Linux XFS
    La documentation d’openrsync ne garantit pas ce type de copie complète ; je pars donc pour l’instant du principe qu’il ne sait pas le faire et je le juge inutile
    Côté archivage, sous Linux, bsdtar peut stocker une copie de fichier presque complète lorsqu’il utilise le format pax, tandis que les anciens formats tar/cpio ne peuvent pas contenir les métadonnées modernes
    Habituellement, j’ai un alias rsync défini sur /usr/bin/rsync --archive --xattrs --acls --hard-links --progress --rsh="ssh -p XXX -l YYYYYYY"
    cp de coreutils peut aussi faire une copie complète avec les bonnes options de CLI et de compilation, mais certaines distributions le compilent sans prise en charge des attributs étendus, ce qui ne produit qu’une copie partielle sans avertissement ni erreur

    • Pour avoir travaillé dans une société de sauvegarde, la plupart des grands comptes ne se soucient pas vraiment que 99 % des métadonnées soient restaurées exactement ; tant que les données reviennent, ça leur va
      Nous restaurons tout avec beaucoup de prudence, mais j’ai parfois l’impression que nous sommes les seuls à nous en préoccuper
    • Ce n’est peut-être qu’une différence de style de documentation
      Par défaut, je verrais openrsync comme un rsync avec moins de contraintes de licence, pas comme quelque chose qui se comporte différemment
      Le README d’openrsync dit qu’il est compatible avec rsync et renvoie à la documentation de rsync
      Si les attributs étendus, les ACL et les timestamps haute résolution ne sont pas des fonctionnalités optionnelles au niveau du protocole, alors pour revendiquer la compatibilité, il faudrait bien prendre en charge tout ce que rsync moderne prend en charge, non ?
      Sinon, je me demande si cela signifie qu’il accepte tout le protocole mais jette simplement des choses comme les ACL
    • OpenRsync vient du projet OpenBSD, ce qui amène généralement à s’attendre à un haut niveau de qualité et à une forte attention à la sécurité
      Cela dit, même le site officiel indique : « We are still working on it... so please wait. »
    • Du point de vue d’Apple, c’est un problème de licence, et peu d’utilisateurs se soucieront de cette différence
      Ceux que ça concerne n’ont qu’à installer rsync
    • J’ai pu trouver dans le code source la liste des arguments qu’openrsync accepte
      --xattrs, --acls et --hard-links, que j’utilise dans mon alias, sont tous absents
      [0]https://github.com/kristapsdz/openrsync/blob/a257c0f495af2b5...

  • En tant qu’utilisateur Linux relativement récent, la gestion des versions des utilitaires système fournis me semble assez chaotique
    Un exemple typique est unzip : les versions d’unzip fournies avec un serveur Debian et un vieux serveur Ubuntu ne savaient pas traiter les ZIP chiffrés en AES-256, alors qu’à en croire Stack Overflow, certaines distributions semblent l’avoir mis à jour pour le prendre en charge
    Le problème, c’est qu’il est difficile de trouver facilement un unzip mis à jour ; tous prétendent être en « version 6.00 » alors que leur comportement réel diffère, et même si on en trouve un, on ne sait pas s’il est sûr de remplacer celui fourni par le système
    Au final, même si quelqu’un a ajouté une bonne fonctionnalité à un utilitaire très utilisé, on ne peut toujours pas vraiment s’en servir ; et comme c’est un utilitaire système central, il donne même l’impression d’être plus difficile à mettre à jour qu’un outil tiers
    Windows ou macOS peuvent être similaires, voire pires, sur les utilitaires système, mais je pensais que Linux gérait mieux ce genre de choses

    • Dans ce cas, mieux vaut utiliser 7z plutôt que unzip
      Sous Linux, je n’ai presque pas le souvenir d’avoir utilisé unzip pour manipuler des ZIP ou des archives en général
      Dans l’esprit de la philosophie Unix, il est aussi naturel d’enchaîner par des pipes de petits outils simples qui font bien une chose : regrouper avec tar, compresser avec gzip, chiffrer avec pgp, etc.
      Côté versions, je ne sais pas exactement pourquoi Debian et Ubuntu annoncent tous les deux 6.00, mais ce n’est pas vraiment courant
      Sur une machine personnelle, une distribution en rolling release comme Arch ou Manjaro suit plus régulièrement les versions amont, mais cela augmente la charge de maintenance et ce qu’on attend de vous en gestion directe
      Ce qui est encore plus gênant dans la gestion des versions sous Linux/open source, c’est que les bibliothèques repoussent beaucoup trop la déclaration d’une v1.00
      Même quand elles sont largement implantées dans l’écosystème, stables et quasiment complètes fonctionnellement, elles restent parfois des années en v0.2 ou v0.68, ce qui embrouille les débutants
    • Debian et Ubuntu ont tendance à lier les versions des outils système à la version de l’OS
      Debian a un cycle de publication long, mais elle est très stable, et dans stable tout fonctionne bien ensemble
      Ubuntu ressemble grosso modo à Debian avec l’idée « et si on publiait plus souvent ? » en plus
      Si l’on veut des outils récents, il faut accepter des options potentiellement moins stables comme Nix ou Arch, et aucune des deux n’est particulièrement conviviale
      Si l’on veut à la fois stabilité et outils récents, Gentoo est une solution, mais elle est encore plus exigeante qu’Arch
      Si l’on veut stabilité et simplicité, on peut sacrifier de l’espace disque avec des approches comme Docker/podman, flatpak, appcontainers ou snap
      Windows et Mac ont le même problème, et Windows l’a historiquement résolu en embarquant d’anciennes bibliothèques et en faisant de l’édition de liens dynamique selon l’application en cours d’exécution
    • unzip est un cas particulier
      Le développement amont est pratiquement à l’arrêt, et la dernière version publiée est la 6.0 de 2009
      Par la suite, plusieurs problèmes ont été découverts et des fonctionnalités ont commencé à manquer ; chaque distribution a donc empilé de nombreux correctifs sur cette version, ce qui a produit des exécutables très différents portant le même numéro de version
      [0] : https://infozip.sourceforge.net/UnZip.html
      [1] : la recette de build d’Arch permet de voir le nombre de correctifs appliqués : https://gitlab.archlinux.org/archlinux/packaging/packages/un...
    • Les distributions sont des projets indépendants, ce genre de différences est donc prévisible
      Un certain degré d’interopérabilité est appréciable, mais la diversité des choix est aussi un avantage
      La plupart des dépôts de distributions proposent bsdtar, qui vaut la peine d’être essayé à la place ; selon la distribution, le paquet peut s’appeler libarchive
      Avec seulement bsdtar xf path/to/file, on peut extraire presque tous les formats, et l’AES dans les ZIP est aussi pris en charge
      Il est inclus par défaut dans macOS, et il l’est probablement aussi dans Windows
    • Oui, c’est bien le bazar, et il vaut mieux moins dépendre des outils intégrés autant que possible
      Pour chaque tâche, je crée un dépôt git et un flake.nix, puis je fais en sorte que direnv active l’environnement déclaré dans le flake quand on entre dans ce répertoire
      Si j’écris un script qui utilise grep, je mets le script dans le dépôt et j’ajoute aussi pkgs.gnugrep à flake.nix
      Ainsi, ce n’est pas la version système qui est utilisée, mais la version déclarée ; et si je passe de macOS à Linux ou WSL, j’appelle la même version de grep
      Nix a souvent la réputation d’être peu accueillant pour les débutants, donc je serais prudent avant de le recommander tel quel, mais l’idée centrale est de déclarer les dépendances d’une manière ou d’une autre et de n’utiliser que les dépendances déclarées
      Docker convient aussi, et les écosystèmes de langages comme Python/Node.js/Go/Rust fournissent également des moyens d’empaqueter et d’appeler les dépendances
      De cette façon, les mises à jour de dépendances restent dans des commits, et si quelque chose casse, on peut revenir au commit précédent
      Ce type de dépôt n’a pas forcément besoin d’être un projet logiciel ; cela peut aussi être « l’ensemble d’outils nécessaires pour faire XYZ »

  • Le fait qu’openrsync ne prenne pas en charge une partie des fonctionnalités de rsync est un peu pénible
    Mais c’est quand même une bonne chose qu’il existe désormais plusieurs implémentations indépendantes de rsync
    Car cela signifie que rsync est traité non pas comme un simple logiciel, mais comme un véritable protocole

    • C’est ce point qui me rend optimiste
      En se rapprochant d’un protocole, on pourrait voir apparaître des points d’accès de type API de diff binaire fondés sur l’algorithme rsync
      Fait intéressant, Dropbox utilisait en interne les diffs binaires de rsync pour téléverser rapidement de petites modifications dans de gros fichiers
      Je pense que c’est encore le cas aujourd’hui, mais comme cette fonctionnalité n’existe pas dans les endpoints d’API publics, il faut renvoyer tout le fichier même lorsqu’un gros fichier ne contient qu’une petite modification
    • En regardant http://github.com/stapelberg/rsync-over-grpc/, on voit un exemple d’utilisation du protocole rsync, plus précisément de l’implémentation https://github.com/gokrazy/rsync, par-dessus gRPC
      C’est assez utile dans les environnements d’entreprise où SSH+rsync est bloqué, mais où la mise en place d’un service gRPC est autorisée
    • Le site indique « We are still working on it... so please wait. »
      rsync ayant beaucoup de fonctionnalités, cela ne peut que prendre pas mal de temps
    • Il existe aussi librsync
    • Je me demande pourquoi cela signifie que rsync est un protocole

  • Dans le patch rsync mainline, la prise en charge des attributs étendus a été ajoutée afin de gérer les métadonnées macOS
    « Carbon Copy Cloner » de Bombich est une application GUI qui l’encapsule
    https://support.bombich.com/hc/en-us/articles/20686446501143...
    J’ai découvert Mike Bombich via des messages sur un forum d’administrateurs système macOS Server, et il existe aussi des ressources à ce sujet
    https://web.archive.org/web/20140707182312/http://static.afp...
    Nathaniel Gray a créé Backup Bouncer, qui vérifie la fidélité des sauvegardes, notamment les flux multiples, les attributs étendus et les ACL
    https://github.com/n8gray/Backup-Bouncer
    Il existe aussi RsyncX, une application SwiftUI qui encapsule rsync
    https://github.com/rsyncOSX/RsyncOSX
    À l’époque où l’on faisait tourner des logiciels macOS « Classic » au-dessus du nouveau système UNIX, ce genre de choses comptait vraiment beaucoup
    https://web.archive.org/web/20161022012615/http://blog.plast...

    • Le problème de rsync, c’est qu’il est absurdement lent
      IFileOperation (Windows) et FileManager (macOS) effectuent la copie la plus performante prise en charge par le système de fichiers sous-jacent
      Avec SMB et ReFS, la vérification CRC relève d’une simple case à cocher, et sur un partage SMB moderne sous Windows Server moderne, l’étape de correspondance de contenu de rsync fait doublon
      Entre machines Windows, IFileOperation peut offrir un débit 1,5 à 8 fois supérieur à rsync, avec une utilisation CPU plus faible, et être aussi 1,2 à 3 fois plus rapide qu’une copie de fichiers Go ordinaire
      Si l’on ne se soucie pas des systèmes d’exploitation qui utilisent réellement des métadonnées de système de fichiers complexes et qu’on ne regarde que Linux, openrsync ou un programme plus simple suffisent

  • Je me demande s’il existe une bonne ressource expliquant pourquoi Apple a si peur de la GPLv3
    J’aurais tendance à penser que compiler statiquement les exécutables ne devrait pas poser problème

    • La GPLv3 a comblé la faille qui permettait de publier le code source d’un produit dérivé de code GPL tout en empêchant l’utilisateur de compiler ce source et de l’exécuter sur l’appareil réel
      À l’époque, TiVo faisait cela, d’où le terme de tivoïsation
      Sur iOS, la raison de ne pas utiliser la GPLv3 est claire : cela violerait ses conditions
      Sur macOS, Apple pourrait embarquer du code GPLv3, mais comme Apple partage beaucoup de code entre iOS, macOS, watchOS, tvOS et visionOS, il n’y a pas grand intérêt à s’appuyer sur du GPLv3 pour un seul système d’exploitation et pas pour les autres
      Le plus simple est de ne pas en utiliser du tout
      De plus, si Apple verrouille davantage l’exécution de code utilisateur sur macOS à l’avenir, elle n’aura pas à se soucier de retirer du code GPLv3 à ce moment-là
    • Mon point de vue sur la GPL et les licences apparentées a beaucoup changé en travaillant avec des avocats
      Des choses que je pensais totalement sûres ne l’étaient pas forcément de manière aussi catégorique du point de vue des avocats
      Je ne connais pas les raisons d’Apple, mais les juristes d’entreprise d’autres sociétés donnaient comme principe de choisir si possible des licences non GPL
    • Il est très probable qu’Apple veuille simplement éviter de se retrouver dans une situation où elle devrait contester la GPLv3 devant un tribunal, avec le risque de perdre
      À en juger par l’historique de la jurisprudence autour de la GPLv2, le gain semble faible au regard des efforts nécessaires
      Du point de vue d’Apple, remplacer simplement les parties perçues comme « problématiques » permet d’éviter toute la catégorie de problèmes
    • Apple est manifestement opposée aux droits des utilisateurs, et la GPL est précisément une licence destinée à protéger ces droits
      Les détails techniques peuvent être intéressants, mais je ne pense pas qu’ils soient au cœur du sujet
    • Apple ne donne pas ses raisons
      Il vaut mieux ne pas trop croire les explications d’autres personnes sur les intentions d’Apple

  • En écrivant directement en Go l’implémentation https://github.com/gokrazy/rsync, j’ai regardé openrsync, et le code était bon
    C’est toutefois dommage qu’openrsync ne soit pas compatible à 100 % avec rsync
    Mes tests ont cassé sous macOS 15, ce qui m’a fait comprendre qu’Apple avait commencé à basculer vers openrsync

  • Il est indiqué qu’openrsync a été écrit dans le cadre du projet rpki-client(1), un validateur RPKI pour OpenBSD, et financé par NetNod, IIS.SE, SUNET et 6connect ; je me demande pourquoi ces organisations ont financé ce développement
    https://github.com/kristapsdz/openrsync?tab=readme-ov-file#p...

    • Cette réponse explique assez bien sa raison d’être
      https://news.ycombinator.com/item?id=43605846
      Les entreprises financent ce qui leur est utile ou nécessaire
      Certaines entreprises de la liste utilisent peut-être BSD, et voulaient ou avaient besoin d’une implémentation de rsync qui ne soit pas sous GPLv3
      Ou bien elles avaient simplement envie de soutenir des projets open source et leur développement

  • Pendant un temps, jusqu’à Sequoia 15.3, on pouvait utiliser à la fois rsync_samba et rsync_openrsync via /var/select/rsync ou la variable d’environnement CHOSEN_RSYNC
    Ce qui est particulièrement agaçant avec openrsync, c’est qu’il prétendait prendre en charge l’élément de chemin magique /./ pour --relative
    J’ai envoyé un rapport de bug à Apple à ce sujet il y a environ un mois
    À partir de Sequoia 15.4, rsync_samba a disparu, et j’ai installé rsync via Homebrew

  • J’ai récemment rencontré ce problème : quand on crée un .ipa iOS avec xcodebuild en ligne de commande, il semble appeler rsync en interne pour copier des fichiers entre des répertoires locaux
    Mais comme le rsync de Homebrew était prioritaire dans $PATH, c’est lui qui a été exécuté, et xcodebuild lui a passé --extended-attributes, un argument propre à openrsync
    Le rsync de Homebrew ne comprend pas cet argument, a échoué et s’est arrêté

  • Je suis quand même content qu’Apple ne supprime pas progressivement le côté POSIX pour transformer osx en quelque chose comme iOS, mais continue au contraire à l’améliorer et à l’assumer