Openrsync - Implementación de rsync del equipo de OpenBSD

 (github.com/kristapsdz)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • openrsync es una implementación de rsync bajo licencia BSD (ISC), y actualmente está integrada en la base de OpenBSD
  • Es compatible con rsync reciente y en las pruebas se usa rsync 3.1.3, pero puede funcionar siempre que haya soporte para el protocolo 27
  • Como no acepta todos los argumentos de línea de comandos de rsync sino solo una parte, al usar openrsync y rsync juntos hay que usar banderas compatibles en ambos lados
  • El sistema operativo oficialmente soportado es OpenBSD, aunque incluye glue de portabilidad para poder compilarse y ejecutarse en otros sistemas UNIX
  • La documentación estándar son las páginas del manual; los detalles del protocolo están en rsync(5) y rsyncd(5), y la documentación de la utilidad está en openrsync(1)
  • El proyecto fue escrito como parte de rpki-client(1) para OpenBSD, y recibió financiamiento de NetNod, IIS.SE, SUNET y 6connect
  • La instalación en sistemas UNIX comunes se realiza con ./configure, make, make install, y no entra en conflicto con una instalación existente de rsync
  • El algoritmo de rsync se divide en sender y receiver; el sender crea la lista de archivos fuente y sus metadatos, y ambos lados ordenan los nombres de archivo alfabéticamente para referenciar los elementos por posición
  • En la sincronización de archivos normales, si el tamaño del archivo y la hora de modificación coinciden se omite; si no, se reconstruyen los datos cambiados usando un hash rápido tipo Adler-32 de 4 bytes y un hash MD4 lento de 16 bytes por cada bloque de tamaño fijo
  • El tamaño de bloque por defecto es el valor redondeado de la raíz cuadrada del tamaño total del archivo, el tamaño mínimo es 700 B, y por una razón desconocida el resultado de la raíz cuadrada se redondea hacia arriba al múltiplo de 8 más cercano
  • La sesión se divide entre el cliente que ejecuta el usuario y un proceso servidor que corre de forma remota; el servidor puede ejecutarse bajo demanda con ssh(1) o funcionar como un demonio de red persistente
  • A diferencia de rsync, donde el generator funciona como un proceso separado junto al receiver, openrsync combina generator y receiver en un solo proceso y responde a solicitudes de lectura y escritura mediante un bucle de eventos
  • En seguridad, usa pledge(2) de OpenBSD para restringir las operaciones del sistema según el modo de ejecución, y unveil(2) para permitir solo el acceso al sistema de archivos bajo el directorio de destino
  • En modo servidor, la semilla del hash MD4 no se genera con time(3) sino con arc4random(3)
  • Puede portarse a Linux (glibc y musl), FreeBSD, NetBSD, Mac OS X y OmniOS, y el CI de GitHub ejecuta pruebas en arquitecturas x86_64, aarch64 y s390x, pero la principal limitación del port es igualar funciones de seguridad equivalentes a pledge y unveil de OpenBSD

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios en Hacker News

  • La explicación de que, si el servidor remoto es el origen o el destino, el cliente crea un hijo con fork(2), inicia el servidor openrsync en el host remoto mediante ssh(1), y luego cliente y servidor se comunican por una tubería socketpair(2), es ambigua sobre cómo se supone que funciona
    Supongo que significa que el hijo creado por fork le pasa la conexión al padre mediante el par de sockets, o que conecta la entrada/salida estándar a la “tubería” del par de sockets y luego hace exec de ssh
    Pero esto es como decir que uno va en auto hasta el aeropuerto y entonces va en auto a Australia

  • He estado usando openrsync desde que se anunció, aquí y allá, y con el tiempo definitivamente ha mejorado. Tengo ganas de que llegue el momento en que pueda usarse por completo
    Pero hay un punto en el que no coincide con Samba rsync para mi patrón de uso: openrsync --rsync-path=openrsync -av -e ssh /etc/services example.com:/tmp/services
    Lo que esperaba era que creara el archivo /tmp/services en el remoto, pero en realidad crea /tmp/services/services
    El mirroring típico de directorios, como -av -e ssh /path/to/src/ example.com:/path/to/dst/, sí se comporta como Samba rsync

    • Eso también parece coincidir con rsync “normal”. Para sincronizar solo el contenido, parece que hace falta una barra diagonal final después de services
      Corrección: en realidad, mi rsync “normal” también era el openrsync de macOS
    • La clave sería si en el destino ya existía el directorio /tmp/services
      Una de las partes más confusas de rsync es cómo maneja los directorios y la barra final
    • Si pones una barra final en el origen, copia desde dentro del directorio; si la omites, copia el directorio en sí. Hasta donde sé, eso es un comportamiento bastante estándar en las herramientas POSIX en general
    • Como alguien a quien rsync ha torturado durante incontables años, entiendo ese impulso, pero creo que crear un segundo services tiene mucho más sentido y es un valor predeterminado más seguro
      Si hay una oportunidad de cambiar el valor por defecto de rsync para que sea menos demencial, hay que salvar a las futuras generaciones de esta confusión

  • Viendo que últimamente han aumentado de golpe los commits de vibe coding en el código base de rsync, y hasta han provocado regresiones, esto es una excelente noticia

    • rsync siempre había sido sólido, así que quise restarle importancia a ese comentario, pero de hecho mis scripts de backup se rompieron después de actualizar
      En los issues recientes de GitHub hay un montón de bugs introducidos en los últimos 2 parches, e incluso un monstruoso commit de unas 9 mil líneas que probablemente no aportó gran cosa
      Los LLM hacen que escribir código sea más rápido y fácil, pero lo importante siempre fue pensar. No entiendo por qué arruinar software tan antiguo y confiable como este

  • Para quien necesite contexto sobre por qué se desarrolló este paquete, este proyecto se está desarrollando actualmente como parte de un validador RPKI
    https://medium.com/@jobsnijders/a-proposal-for-a-new-rpki-va...

  • También hay una implementación en Go de Michael Stapelberg / el equipo de Gokrazy: https://github.com/gokrazy/rsync

  • La esencia del trabajo real de portabilidad es igualar las funciones de seguridad que ofrecen pledge(2) y unveil(2) de OpenBSD. Son elementos decisivos para la funcionalidad del sistema
    Sin esas funciones, el sistema terminaría aceptando datos arbitrarios desde la red pública
    https://justine.lol/pledge/
    En Alpine Linux edge no parece estar pledge. ¿Alguien ha probado Pledge en Linux? ¿Estoy entendiendo mal el riesgo de usar openrsync sin pledge, o este artículo está pensado solo para usuarios de OpenBSD?

    • Linux no tiene cosas como pledge, unveil o Capsicum. Tiene cgroups, espacios de nombres y un montón de piezas sueltas que hay que combinar para lograr algo parecido
      Linux no fue construido tanto como una función integral de aislamiento provista por determinadas llamadas al sistema y rutas del kernel, sino como varios sistemas que se fueron agregando repetidamente y se combinan entre sí para construir sandboxing o restricción de capacidades
      Parece que hoy en día Linux también tiene funciones nuevas como Landlock, pero probablemente estén construidas sobre componentes básicos ya existentes de Linux, en lugar de ser algo totalmente nuevo
      Decir que es un “desastre” probablemente significa que está disperso por todos lados. Hay demasiadas formas de bloquear cosas, y para elegir la mejor hay que meterse a fondo en cada subsistema, en contraste con usar solo una o dos llamadas al sistema sencillas
    • Arriba de la parte citada dice esto: “El único sistema operativo soportado oficialmente es OpenBSD, porque cuenta con características de seguridad considerables”
      Y abajo dice esto: “Parece posible con Capsicum de FreeBSD, pero las instalaciones de seguridad de Linux son un desastre y se necesitaría la mano de un experto para asegurarlo correctamente”
      O sea, que sea portable significa que compila y corre, no que tenga las mismas funciones de seguridad
      Estaría bien que pledge/unveil llegaran a Linux upstream, pero no lo espero
    • Esa cita parece tan simplificada en exceso que casi resulta completamente falsa
      A diferencia de la frase “sin estas funciones el sistema acepta datos arbitrarios desde la red pública”, pledge y unveil no cambian si acepta o no datos arbitrarios. Lo que hacen es restringir lo que puede hacer un proceso una vez comprometido por una vulnerabilidad
      En la sección Security sí está explicado correctamente, así que no sé de dónde salió esa formulación

  • Esta es la versión que empezó a usarse desde macOS 15.0

    • ¿Fue en 15.0? Yo recordaba que había llegado en alguna de las versiones menores de la rama 15.x, y recuerdo que algunos scripts se rompieron sin razón aparente
      Corrección: curiosamente sí la incluyeron en 15.0, pero parece que se guardaron los cambios incompatibles que rompían cosas hasta 15.4. https://apple.stackexchange.com/a/479297

  • Como no soporta el protocolo rsync reciente, no tiene soporte para marcas de tiempo de 64 bits, y por eso en sistemas de archivos nuevos no puede sincronizar realmente los metadatos

  • Me da curiosidad por qué se llama así. Openrsync suena como una alternativa de código abierto a un programa de código cerrado
    Pero Rsync original, ¿no era GPL también? ¿Solo significa que es “más abierto” por tener una licencia más permisiva?

    • La gente de OpenBSD probablemente diría que la GPL es menos abierta por exigir que las obras derivadas también se distribuyan bajo GPL
    • Entre los proyectos cercanos a OpenBSD hay muchos que empiezan con open, como openssh, openbgpd, openntpd y opensmtpd