Openrsync - l’implémentation de rsync par l’équipe OpenBSD

• openrsync est une implémentation de rsync sous licence BSD (ISC), actuellement intégrée à la base d’OpenBSD
• Compatible avec les versions récentes de rsync ; les tests ont été effectués avec rsync 3.1.3, mais le fonctionnement est possible dès lors que le protocole 27 est pris en charge
• Comme openrsync n’accepte qu’une partie des arguments en ligne de commande de rsync, il faut utiliser les drapeaux pris en charge des deux côtés lorsqu’on emploie openrsync et rsync ensemble
• Le système d’exploitation officiellement pris en charge est OpenBSD, mais des couches de glue de portabilité sont incluses pour permettre la compilation et l’exécution sur d’autres systèmes UNIX
• La documentation standard se présente sous forme de pages de manuel ; les détails du protocole figurent dans rsync(5) et rsyncd(5), tandis que la documentation de l’utilitaire est disponible dans openrsync(1)
• Le projet a été écrit dans le cadre d’une partie de rpki-client(1) pour OpenBSD, avec un financement de NetNod, IIS.SE, SUNET et 6connect
• L’installation sur un système UNIX standard s’effectue avec ./configure, make, make install, sans entrer en conflit avec une installation existante de rsync
• L’algorithme rsync est divisé entre un sender et un receiver ; le sender construit la liste des fichiers source et les métadonnées, puis les deux côtés trient les noms de fichiers par ordre lexicographique afin de référencer les éléments par position
• Pour une synchronisation classique de fichiers, si la taille du fichier et l’heure de modification sont identiques, le fichier est ignoré ; sinon, les données modifiées sont reconstruites bloc par bloc à l’aide d’un hash rapide de type Adler-32 sur 4 octets et d’un hash MD4 plus lent sur 16 octets
• La taille de bloc par défaut correspond à la racine carrée de la taille totale du fichier, arrondie ; la taille minimale est de 700 B, et le résultat de la racine carrée est, pour une raison inconnue, arrondi au multiple de 8 supérieur
• Une session se compose d’un client lancé par l’utilisateur et d’un processus serveur exécuté à distance ; le serveur peut être lancé à la demande via ssh(1) ou fonctionner comme un démon réseau persistant
• Contrairement au generator de rsync, qui fonctionne comme un processus séparé à côté du receiver, openrsync fusionne le generator et le receiver en un seul processus et répond aux requêtes de lecture et d’écriture via une boucle d’événements
• Sur le plan de la sécurité, OpenBSD utilise pledge(2) pour limiter les opérations système selon le mode d’exécution, et unveil(2) pour n’autoriser l’accès au système de fichiers qu’au répertoire de destination et à son contenu
• En mode serveur, la graine du hash MD4 est générée avec arc4random(3) et non avec time(3)
• Le portage est possible sur Linux (glibc·musl), FreeBSD, NetBSD, Mac OS X et OmniOS, et la CI GitHub exécute des tests sur les architectures x86_64, aarch64 et s390x ; toutefois, la principale contrainte du portage reste la reproduction de fonctions de sécurité équivalentes à pledge et unveil d’OpenBSD

[GN⁺]

Commentaires Hacker News

• Quand la machine distante est la source ou la destination, l’explication disant que le client crée un processus fils avec fork(2), lance openrsync serveur sur l’hôte distant via ssh(1), puis que le client et le serveur communiquent via un tube socketpair(2), reste assez ambiguë sur le fonctionnement réel.
  J’imagine que cela veut dire que le fils issu du fork transmet la connexion au parent via la paire de sockets, ou bien qu’il relie l’entrée/sortie standard au « tube » de la paire de sockets puis fait un exec de ssh.
  Mais c’est un peu comme dire qu’on va en Australie en voiture sous prétexte qu’on va d’abord en voiture jusqu’à l’aéroport.

• J’utilise openrsync ici et là depuis son annonce, et il s’est clairement amélioré avec le temps. J’attends avec impatience le moment où je pourrai l’utiliser entièrement.
  Cela dit, dans mon usage il y a un point où il ne correspond pas au rsync de Samba : openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
  Le comportement attendu serait de créer le fichier distant /tmp/services, mais en pratique il crée /tmp/services/services.
  Les cas classiques de miroir de répertoires comme -av -e ssh /path/to/src/ example.com:/path/to/dst/ se comportent comme le rsync de Samba.

  • Ce comportement semble aussi conforme au rsync « normal ». Pour synchroniser uniquement le contenu, il faut sans doute un slash final après services.
    Correction : en fait mon rsync « normal » était lui aussi l’openrsync de macOS.
  • Tout dépend de l’existence préalable d’un répertoire /tmp/services côté destination.
    L’un des aspects les plus déroutants de rsync, c’est justement la gestion des répertoires et des slashs finaux.
  • Si on met un slash final à la source, on copie le contenu du répertoire ; si on l’omet, on copie le répertoire lui-même. À ma connaissance, c’est un comportement assez standard dans l’ensemble des outils POSIX.
  • Après avoir été tourmenté par rsync pendant un nombre incalculable d’années, je comprends cette réaction, mais créer le deuxième services est bien plus logique et constitue une valeur par défaut plus sûre.
    S’il y a une occasion de rendre les valeurs par défaut de rsync un peu moins folles, il faut épargner cette confusion aux générations futures.

• Vu l’augmentation soudaine des commits de vibe coding dans la base de code de rsync, avec en plus des régressions, c’est une excellente nouvelle.

  • rsync a toujours été robuste, donc j’étais tenté de balayer ça d’un revers de main, mais après une mise à niveau, mon script de sauvegarde s’est réellement cassé.
    Les derniers tickets sur GitHub recensent pas mal de bugs introduits dans les deux patchs récents, y compris un commit monstrueux d’environ 9 000 lignes qui n’avait probablement aucun intérêt.
    Les LLM rendent l’écriture de code plus rapide et plus facile, mais le plus important a toujours été de réfléchir. Je ne comprends pas pourquoi on saccage un logiciel aussi ancien et aussi fiable.

• Pour ceux qui ont besoin du contexte de développement de ce paquet, ce projet est actuellement développé comme partie d’un validateur RPKI.
  https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...

• Il existe aussi une implémentation en Go par Michael Stapelberg / l’équipe Gokrazy : https://github.com/gokrazy/rsync

  • Même si on parle de l’équipe Gokrazy, en pratique c’est essentiellement Michael Stapelberg : )
    https://github.com/gokrazy/rsync/graphs/contributors

• Le cœur d’un vrai portage, c’est d’égaler les fonctions de sécurité fournies par pledge(2) et unveil(2) d’OpenBSD. Elles sont déterminantes dans le fonctionnement du système.
  Sans elles, le système finit par accepter des données arbitraires depuis le réseau public.
  https://justine.lol/pledge/
  Sur Alpine Linux edge, je ne vois pas pledge. Quelqu’un a-t-il déjà testé Pledge sur Linux ? Est-ce que je comprends mal le risque d’utiliser openrsync sans pledge, ou bien cet article s’adresse-t-il uniquement aux utilisateurs d’OpenBSD ?

  • Linux n’a ni pledge, ni unveil, ni Capsicum. Il y a les cgroups, les espaces de noms, et divers autres éléments qu’il faut combiner pour obtenir quelque chose d’approchant.
    Sous Linux, ce n’est pas tant un mécanisme d’isolation global fourni par quelques appels système et chemins noyau spécifiques, mais plutôt une accumulation de systèmes ajoutés au fil du temps et combinables pour construire un sandboxing ou des restrictions de capacités.
    Il semble aussi y avoir des nouveautés comme Landlock côté Linux ces temps-ci, mais j’imagine que cela s’empile sur les briques Linux existantes au lieu de repartir de zéro.
    Parler de « bazar » signifie sans doute surtout que tout est dispersé. Il existe trop de façons de verrouiller les choses, et choisir la meilleure oblige à creuser chaque sous-système en détail. Rien à voir avec l’usage de seulement un ou deux appels système.
  • Juste au-dessus du passage cité, on lit : « Le seul système d’exploitation officiellement pris en charge est OpenBSD, parce qu’il dispose de fonctions de sécurité substantielles. »
    Et plus bas : « Ce serait probablement possible avec Capsicum sur FreeBSD, mais les mécanismes de sécurité de Linux sont un bazar et il faut l’intervention d’un expert pour le sécuriser correctement. »
    Donc portable signifie ici que cela compile et s’exécute, pas que cela offre les mêmes garanties de sécurité.
    Ce serait bien que pledge/unveil arrivent un jour dans l’amont Linux, mais je n’y crois pas trop.
  • La citation simplifie tellement à l’excès qu’elle en devient presque entièrement fausse.
    Contrairement à l’idée que « sans ces fonctions le système accepte des données arbitraires depuis le réseau public », pledge et unveil ne changent pas le fait d’accepter ou non des données arbitraires. Ils limitent ce qu’un processus compromis par une faille peut faire.
    La section Security l’explique correctement, donc je ne sais pas d’où vient cette formulation.

• C’est la version utilisée à partir de macOS 15.0.

  • C’était 15.0 ? J’avais en tête que c’était arrivé dans l’une des versions mineures de la série 15.x, et je me souviens que certains scripts s’étaient cassés sans raison apparente.
    Correction : amusant, Apple l’a bien inclus dès 15.0, mais a visiblement gardé les changements cassant la compatibilité descendante pour 15.4. https://apple.stackexchange.com/a/479297

• Comme il ne prend pas en charge le protocole rsync récent, il n’a pas de support des horodatages 64 bits, et ne peut donc pas réellement synchroniser les métadonnées sur les systèmes de fichiers récents.

• Je me demande pourquoi ce nom. Openrsync donne l’impression d’une alternative open source à un programme propriétaire.
  Pourtant, Rsync n’est-il pas déjà sous GPL ? Cela veut-il simplement dire « plus ouvert » grâce à une licence plus permissive ?

  • Du point de vue des gens d’OpenBSD, l’obligation d’appliquer la GPL aux œuvres dérivées rend la GPL moins ouverte.
  • Parmi les projets étroitement liés à OpenBSD, beaucoup commencent par open : openssh, openbgpd, openntpd, opensmtpd, etc.