rsync y la indignación

• El mantenimiento de rsync enfrenta una explosión de reportes de seguridad y la controversia por el uso de IA, en una situación donde se volvieron necesarios mejores pruebas, cobertura de código, CI multiplataforma, escaneo de seguridad y defensa en profundidad
• La nueva suite de pruebas en Python reemplaza la estructura anterior basada en scripts de shell, pero el diseño y el plan de validación quedaron a cargo del mantenedor, mientras que Claude, Codex y Gemini se usaron como apoyo en tareas repetitivas
• La versión 3.4.3 fue un lanzamiento que priorizó correcciones de seguridad, pero en el proceso introdujo regresiones en algunos casos de uso válidos pero poco comunes que ni las pruebas existentes ni las pruebas manuales detectaron
• Aunque ha usado mucho pytest en otros proyectos, consideró que no se ajustaba a ciertos requisitos específicos de la suite de pruebas de rsync y por eso diseñó un enfoque aparte; su postura es que los LLM deben usarse con cuidado, pero siguen siendo herramientas útiles
• La dirección futura aún se decide entre una 3.4.4 para mitigar regresiones y una 3.5.0 con grandes cambios de seguridad; meanwhile, openrsync actualmente falla 85 de 98 pruebas en la nueva suite

---

Explosión de reportes de seguridad y refuerzo de defensas

• El mantenedor de rsync está viviendo, como otros desarrolladores de paquetes open source recientemente, una avalancha de reportes de seguridad; muchos de ellos son generados por IA, aunque también existen algunos análisis manuales cuidadosos y de alto nivel
• A medida que aumentaron los reportes, rsync llegó a un punto en el que necesitaba una suite de pruebas más rigurosa, análisis de cobertura de código, pruebas de CI en más plataformas, escaneos deliberados de problemas de seguridad y técnicas de defensa en profundidad
• El mantenedor ya está retirado y quiere dedicar más tiempo a navegar, pero debido al volumen de trabajo necesario utilizó varias herramientas de IA y no se arrepiente de esa decisión

Suite de pruebas en Python y trabajo asistido por IA

• La suite de pruebas original de rsync, basada en scripts de shell, fue reescrita en Python, con una estructura en la que el diseño central y el plan de validación estuvieron directamente a cargo del mantenedor
• Claude se usó para tareas repetitivas, y Codex y Gemini para verificación cruzada; no fue un caso de simplemente pedir “convierte la suite de pruebas a Python” y dejarlo ahí
• El mantenedor revisó personalmente cada parte, invirtió mucho tiempo de CI para ajustarla y después pasó a ejecutar la mayoría de las pruebas en varias VM locales para reducir los tiempos de espera de CI
• La marca co-authored by claude en el historial de commits, en su opinión, solo muestra una parte del trabajo total de ingeniería de software realizado

Debate sobre los LLM, elección de pytest y regresiones en 3.4.3

• Su postura es que los LLM no se vuelven inútiles solo porque se conozca cómo funcionan; hay que usarlos con cuidado, pero en el entorno actual de ingeniería de software y mantenimiento de seguridad en TI siguen siendo útiles
• rsync 3.4.3 fue un lanzamiento deliberadamente inclinado a priorizar la corrección de problemas de seguridad, y en ese proceso algunos casos de uso válidos pero inusuales se vieron afectados por los cambios
• Esos casos afectados no estaban incluidos en la suite de pruebas existente de rsync ni en las pruebas manuales, y las regresiones reportadas a través de issues y PR en el repositorio de GitHub se están atendiendo una por una
• Aunque ha usado mucho pytest en otros proyectos, concluyó que parte de lo que necesitaba hacer en la suite de pruebas de rsync era muy difícil con pytest, por lo que optó por diseñar un enfoque de pruebas independiente

Próxima versión y expansión de las pruebas de seguridad

• Los reportes de seguridad siguen llegando y actualmente hay varios trabajos de CVE en curso
• Se han sumado otros desarrolladores con capacidad de desarrollo de sistemas y conocimientos de seguridad; algunos de ellos se hicieron visibles precisamente a raíz de la indignación reciente
• La próxima decisión está entre una 3.4.4 que alivie algunas regresiones y una 3.5.0 con cambios mucho más grandes; la 3.5 elevaría de forma importante el estándar de seguridad de rsync, pero sería un lanzamiento de gran magnitud
• Para aplicar con rapidez un conjunto grande de cambios, un software como rsync necesitaba una suite de pruebas integral, y la reescritura de la nueva suite surgió de esa necesidad
• La versión 3.5 incluirá pruebas adicionales para abordar problemas relacionados con la seguridad

Comparación con openrsync y pedido de revisión de código

• Frente a la idea de empaquetar openrsync para ciertas plataformas, la reacción fue que podía probarse la nueva suite de pruebas de rsync sobre openrsync
• El ejemplo de ejecución es el siguiente comando

./runtests.py — rsync-bin=../openrsync/openrsync — use-tcp

• openrsync actualmente falla 85 de las 98 pruebas, y aunque muchos de esos fallos se deben a funciones que openrsync no implementa, la evaluación es que no es un buen resultado
• En lugar de expresar más indignación, pide que se revise de verdad el código publicado y se hagan críticas constructivas

[GN⁺]

Opiniones en Lobste.rs

• Por la cita, se entiende que el autor quiere irse a navegar, pero aun así siente la presión de mantener el proyecto, y vio en usar LLM una solución para poder hacer ambas cosas
  Está bien disfrutar de la jubilación y de navegar sin corregir bugs, y también está bien no corregir bugs en un proyecto de código abierto. Solo hace falta decirlo de forma pública y transparente. Como se decía antes, con un “patches welcome” basta. Más aún si empresas con muchos recursos dependen de ese proyecto
  Ojalá más mantenedores y desarrolladores pudieran disfrutar de su jubilación y de navegar sin la presión de tener que apoyarse en la “ayuda” de los LLM para mantener software de código abierto. Aun así, si quiere experimentar con LLM en el proyecto rsync, es su decisión. Lo mismo aunque otras personas, incluyéndome, no estén de acuerdo
  Sea cual sea la razón, quienes acosan a desarrolladores de código abierto parecen olvidar que el software libre y de código abierto gratuito no es un producto, sino un regalo

  • Está bien que la gente use su tiempo para mantener buen software de código abierto
    Quienes solo miran desde afuera, si no les gusta, pueden hacer un fork. Andrew puede trabajar en ese proyecto como quiera, y tampoco necesita necesariamente nuestros comentarios ni opiniones
  • Como referencia, Tridge volvió a rsync después de que el mantenedor anterior se quemara hasta cierto punto, así que esa interpretación no está completamente equivocada
    La parte esperanzadora es que, a largo plazo, podría aparecer otra persona para encargarse del mantenimiento de rsync. Tridge ya lo entregó antes a un nuevo mantenedor
    Escuché una charla sobre casos en los que la OpenJS Foundation dio financiamiento y apoyo para la transición en algunos proyectos, pasando de un único mantenedor a mantenimiento en equipo, y escribí un artículo para LWN; se publicará hoy. Proyectos como rsync necesitan mucho más este tipo de apoyo
  • Lo interpreté como que el autor buscaba empatía y recordaba que él también es una persona con deseos en conflicto, y que en particular los problemas de seguridad son una gran carga para los mantenedores de código abierto
    Los problemas de seguridad generan mucha presión, tienen mucha visibilidad y a menudo están alejados del núcleo del proyecto que sí le interesa al mantenedor
    El mantenimiento implica mucha responsabilidad y no todo es agradable, pero agradezco cuando los mantenedores de software libre y de código abierto se encargan incluso de ese tipo de trabajo. No parece que haya mucha gente dispuesta a hacerlo
  • La expresión “depender de un LLM” suena como si el resultado fuera a empeorar, pero no necesariamente es así
    Puede que se considere que el costo de lograr cierto objetivo sin ayuda de un LLM es demasiado alto, mientras que con ayuda de un LLM pase a ser razonable
    Visto de forma positiva, esto significa que un mantenedor de código abierto que quiere conservar un equilibrio sano entre trabajo y vida personal puede reducir su carga con LLM y aun así alcanzar más fácilmente los objetivos que quiere
  • Esa interpretación parece haber decidido la conclusión antes de leer el resto del texto
    La parte citada es solo una sección de la introducción, y este texto claramente fue escrito con cuidado y matices, no es un texto básico sobre mantenimiento de código abierto
    Más raro todavía es que se omitió el contexto inmediatamente anterior a la cita. Ahí se dice que, al dispararse los reportes, hubo que elevar mucho la línea defensiva de rsync, y que hacían falta una batería de pruebas mucho más exhaustiva, análisis de cobertura de código, pruebas de CI en más plataformas, búsqueda de problemas de seguridad y la incorporación de técnicas de defensa en profundidad
    En este caso el autor está retirado, pero en otros proyectos de código abierto puede pasar que personas con trabajo u otras ocupaciones queden arrastradas por un aumento similar de la carga de trabajo. Sinceramente, me desconcierta que este comentario tenga tantos votos; no se siente como un texto escrito de buena fe. Como mínimo, parece una reacción descuidada que apenas está un poco por encima de un comentario dejado por alguien que llegó corriendo solo tras leer el título

• No pretendo justificar ni aprobar el acoso, pero a esta defensa le falta el motivo
  La explicación es que el autor hizo el diseño para vibe coding, revisó el código resultante, domina tanto el código como los chatbots, trató el vibe coding con cautela e intentó equilibrar seguridad y regresiones funcionales. Suena plausible, pero en la práctica sí hubo regresiones, y el autor ni siquiera logra llegar a la razón de eso
  Dijo que “las herramientas de IA son buenas para tareas simples, así que les delegué ese tipo de trabajo”, pero no es así. Los chatbots en realidad son malos para escribir. Ese es el punto clave, y parece que el autor ni siquiera lo reconoce

  • Sería interesante hacer un recuento real en una línea de tiempo de cuántas regresiones hubo después de cada release
    Estaría bien comprobar si de verdad los números aumentaron últimamente. Las regresiones en sí no son algo raro, y creo que tal vez la gente solo busca un pretexto para atacar a Andrew
  • ¿Por qué el problema tendría que ser el agente de código? Tal vez el problema es que no hay una batería de pruebas o que no está suficientemente especificada, o quizá que el mantenedor perdió más comprensión del codebase de la que cree
  • No sé si de verdad leímos el mismo texto
    El autor reconoció que hubo regresiones en algunos casos de uso de la release rsync 3.4.3, explicó que en esa release deliberadamente se dio más peso a corregir problemas de seguridad, y que algunos casos de uso válidos pero poco comunes se vieron afectados por los cambios
    Esos casos no estaban incluidos en la batería de pruebas existente de rsync ni en las pruebas manuales que realizó, y dijo que ahora está gestionando las regresiones y agradece a quienes las reportaron mediante issues o PR en el repositorio de GitHub. También pidió disculpas si tu caso de uso se vio afectado, y dijo que si alguien está dispuesto a asumir el riesgo de seguridad, puede usar la release anterior

• Llevo como medio año escuchando una y otra vez que “el mundo de la ingeniería de software cambió drásticamente en los últimos meses” y que “el mundo de mantener software en medio del aluvión de seguridad informática y reportes cambió por completo en las últimas semanas”, y ya cansa.
  Si la causa de este aluvión de reportes son los LLM, buscar la solución en los LLM se siente como una dirección increíblemente equivocada.
  Aun así, sí puedo creer de inmediato que mantener cualquier cosa popular en este momento debe ser horrible. Tal vez para él lo mejor sea simplemente dar un paso al costado y disfrutar de un retiro de verdad, en vez de exprimir aún más su tiempo de cómputo limitado.

  • También cansa el discurso en defensa del vibe coding. Casi se siente como ver un culto.
    Si fuera una herramienta tan útil como asegura al menos la mitad de la gente, su utilidad hablaría por sí sola.
    Aun así, vale la pena escuchar a alguien como Tridgell. Y la “inundación” de reportes de seguridad debe tomarse en serio. No importa quién o qué los haya encontrado: un problema de seguridad sigue siendo un problema de seguridad. Por eso este texto se siente distinto del ataque aburrido de siempre.
  • Me hace sospechar que hay gente beneficiándose de convencer a todos de que la respuesta a los problemas sistémicos creados por los LLM es que todos compren más LLM.
    Al final podríamos entrar en una espiral descendente de dependencia cada vez mayor de los LLM.
  • Del mismo modo, se parece a eso de decir que “la web está tan llena de páginas generadas por IA para granjas de clics que la búsqueda web ya no sirve, así que mejor usa directamente un LLM”.
  • ¿Podrías explicar un poco más esta parte? Yo interpreté que el autor decía que un LLM es útil para procesar los problemas de seguridad reportados.
    ¿Por qué sería esa la dirección equivocada? ¿Quieres decir que sería mejor que nadie tuviera LLM?
  • También cansa igual que se demonice el uso de LLM. Ya aburre llamar vibe coding al desarrollo asistido por LLM dirigido por personas, y también aburre ver a cientos de personas atacar un proyecto o a un desarrollador solo por haber revelado aunque sea un poco de uso de IA.
    El desarrollo asistido por LLM no tiene por qué producir necesariamente “basura”.

• Agradezco que este texto se haya escrito y compartido. En particular, me llamó la atención la parte donde se preguntan si mitigar algunas regresiones con la 3.4.4 o irse por la 3.5.0, que trae cambios mucho más grandes.
  Si el autor está leyendo esto, aquí 3.4.4 parece el enfoque correcto. Después de una situación en la que hubo regresiones en la versión anterior, si se van directo a una 3.5.0 grande, mucha gente lo verá como una imprudencia. Si se ayuda a la gente a entender mejor la diferencia, se reducen las preocupaciones.
  Sobre la parte en la que dice que tal vez fue mala idea intentar trabajar primero en público sobre la estructura central del nuevo test suite en master, dado que eso provocó enojo: no creo que reducir la transparencia vaya a mejorar la percepción ni la reacción. A lo mucho solo aplazaría una reacción todavía mayor.
  No es justo decirle a openrsync que ejecute el nuevo test suite de rsync. samba rsync es protocolo 32 y openrsync es protocolo 27, y además ni siquiera presume de tener paridad total de funciones.

  • Creo que esa era la intención. Básicamente significa que está así de atrasado, así que buena suerte.
  • Una idea sería seguir con el trabajo de 3.5, pero sacar una versión alfa e invitar a revisión y testers.

• Medium y Cloudflare: una combinación horrible que no debería mezclarse.
  https://archive.is/qbyVA
  Mantener software de código abierto es un trabajo poco agradecido. Tridge intentó arreglar la deuda técnica del test suite y responder con responsabilidad al aluvión de CVE detectados por LLM, pero parece que le pegó la ley de Hyrum. El plan de 3.4.4 es la opción menos mala, y al final parece que solo queda seguir adelante.

• Este tema me divide. Por un lado, creo que la seguridad solo puede garantizarse cuando una persona escribe el código directamente
  porque mientras lo escribe va pensando en ese código y detecta errores temprano. Yo escribo mucho mejor el código cuando lo hago yo mismo que cuando lo reviso. Durante la revisión, como no pensé cuidadosamente cada línea, muchas cosas simplemente se me pasan
  Por otro lado, aparte del hecho básico de que el acoso es inaceptable, Andrew tiene derecho a manejar su proyecto en su tiempo libre como quiera. Si quiere usar LLM, yo no estoy de acuerdo, pero es su proyecto y queda a su criterio. Si no me gusta, tendría que mover mis respaldos a restic o borgbackup, o hacer un fork de rsync
  Para ser claro, no me opongo al vibe coding en sí. En el trabajo me hacen usarlo medio a la fuerza, y para escribir código pegamento aburrido y nada novedoso, que es la mayor parte de mi trabajo hoy en día, más o menos sirve. Solo que no lo uso en mi tiempo libre

  • En general estoy de acuerdo. En cuanto a respaldos, rsync tampoco es una solución particularmente adecuada
    porque no ayuda a restaurar cuando el contenido de un archivo se corrompe. Una herramienta como restic es mucho mejor, y además conserva versiones anteriores de los archivos para manejar casos así. De hecho, también rastrea eliminaciones, así que sabe qué archivos ya no son relevantes
  • Me parece parecido a un chiste como “en teoría la teoría es más importante, pero…”
    Tengo experiencia en seguridad de aplicaciones, puedo elegir algunos exploits y también detectarlos en revisión. Pero no soy tan bueno como los LLM punteros actuales cuando se trata de iterar con algo como “busca casos más patológicos”
    En software tan popular he encontrado problemas en mi código, en bibliotecas usadas y en implementaciones alternativas sin esforzarme demasiado. El tiempo y la terquedad que puede aportar una persona no se comparan en absoluto
  • A menudo pensamos en la seguridad como programación segura al procesar entradas no confiables, pero eso es solo una parte de garantizar la seguridad
    En toda la organización suele haber bastante software de seguridad desplegado para prevenir, detectar y responder a incidentes. Siempre hay huecos en cada área y siempre queda más por hacer. Una organización puede preferir adoptar mejoras en su postura de seguridad, aun sabiendo que no será perfecta, antes que no tener ninguna mejora. Los compromisos que ofrece un LLM forman parte de eso
    Ese punto de equilibrio cambia según el contexto, pero rara vez termina siendo “todo el código debe escribirse a mano”
    También aplica a un servidor como rsync. Como dice el autor, quizá haga falta una gran refactorización para volverlo más sólido y resiliente. Si con un LLM se puede refactorizar hacia separación de privilegios para crear una base de código de confianza más pequeña, quizá se puedan aceptar algunos bugs fuera de ese alcance
    No conozco el contexto específico de rsync, pero quiero creer que, dentro de los recursos limitados que suelen tener estos proyectos, el autor está tomando la mejor decisión para el proyecto y para los usuarios
  • Si al detectar cambios en archivos te parece bien reenviar el archivo completo en lugar de usar la transferencia diferencial inteligente y el algoritmo de minimización de datos de rsync, entonces rclone también es una opción
    A cambio, rclone tiene paralelismo, así que aprovecha mucho mejor el ancho de banda de red disponible
  • La formulación me suena un poco rara. Yo pensaba que la seguridad se beneficia de cosas como garantías y pruebas matemáticas impuestas por la automatización, incluso cuando el código cambia
    Eso da un límite superior a los problemas que puede haber
    El límite inferior son los bugs y vulnerabilidades que encuentre yo, que encuentre otra persona, o que encuentre otra cosa, por ejemplo un LLM
    La situación de una persona revisando código en C que ella misma escribió, como rsync, difícilmente puede llamarse una buena posición dentro de ese espectro. No lo digo para culpar a Andrew en absoluto

• Puedo empatizar con un mantenedor retirado que quiere irse a navegar, pero no creo que ese contexto cambie nada de fondo
  Tridgell no nos debe ningún trabajo y es libre de retirarse e irse a navegar. Si eso es lo que quiere hacer, le deseo lo mejor. Entiendo el sentido de responsabilidad, pero si leí bien entre líneas, parece que hasta cierto punto lo vive como una carga
  Pero rsync es software crítico, y creo que quien quiera mantenerlo tiene que cumplir cierto estándar de calidad. Si el trabajo del mantenedor no alcanza ese estándar, eso es un error. Eso no significa que merezca acoso. Decir que algo es un error no significa que la persona que lo cometió sea mala ni que uno no pueda empatizar con ella
  Así que la pregunta es si el trabajo hecho con herramientas de codificación con IA cumplió el estándar. Y el estándar es, más o menos, “¿es mejor tener este trabajo con esta calidad que no tenerlo?”. Si mejora el software, que siga; si lo empeora, que se detenga. No digo que sea una definición brillante, pero sí creo que es la correcta
  No tenemos derecho a exigirle trabajo extra a Tridgell, pero sí hay espacio para decir “esto empeora las cosas para los usuarios”, si eso es cierto
  Sinceramente, todavía no tengo una opinión completamente formada sobre cómo juzgar este trabajo. Hubo una regresión, y Tridgell la explicó como un caso límite, pero sin más contexto no sé cómo comparar el impacto de esa regresión de caso límite con el valor de corregir posibles problemas de seguridad
  Puede que a alguien se le ocurra “WITHOUT ANY WARRANTY”, pero esa cláusula no viene al caso aquí. Es una renuncia a responsabilidad legal, no una renuncia al orgullo artesanal ni a la exigencia no legal de hacer el mejor trabajo posible. Este comentario también se ofrece “WITHOUT ANY WARRANTY”, pero si me equivoco, obviamente pueden criticarme

  • No. El open source no funciona así, ni tiene por qué funcionar así
    El autor no decidió convertirlo en software crítico. Si tú o cualquier otra persona lo usan, la responsabilidad es del usuario. Si el software no funciona como esperas, puedes hacer un fork o reemplazarlo. Lo que no puedes hacer es obligar a esa persona a moverse al ritmo que tú le marques

• Contexto para quienes se perdieron el reporte original de la regresión: https://github.com/RsyncProject/rsync/issues/929

  • El contexto es valioso, pero como la issue de GitHub todavía no está bloqueada, quizá sea mejor no enlazarla directamente
    El reporte de la issue es una captura de pantalla de este mastodon post, y después siguieron más de 300 comentarios de discusión
  • La issue real es este enlace: https://github.com/RsyncProject/rsync/issues/897

• No lo expliques, solo sigue haciendo lo de siempre. A la gente a la que no le gusta, le seguirá sin gustar
  La gente empezó a odiarlo desde que dejaron de escribir ensamblador, y no van a parar en el futuro

  • Esto es claramente falso. Mucha gente se opone a los LLM no porque no le interesen las mejoras en los lenguajes de programación y los entornos de desarrollo, sino precisamente por ese interés