Cuarenta y ocho. Ese es el número de parche al que llegó Symfony 6.4 esta semana, y me gustaría que cada responsable técnico de Laravel se quedara mirándolo un momento. Cuarenta y ocho veces alguien entró en una rama de soporte a largo plazo, encontró algo mal, lo arregló y lo etiquetó. La mayoría nunca miramos ninguna de esas etiquetas. Creo que eso tiene que cambiar. Si tu aplicación corre sobre Laravel, buena parte del código que gestiona tus peticiones y tus comandos de artisan vive en vendor/symfony, y el changelog de ese directorio debería estar en tu lista de lecturas, justo al lado del de Laravel.

El caso de esta semana es de lo más concreto. Han salido correcciones de seguridad para el componente Yaml y para HttpFoundation. HttpFoundation es el que me quitaría el sueño. Cada objeto Request que reciben tus controladores es un Request de Symfony con chaqueta de Laravel, así que un fallo ahí es un fallo en tu aplicación, aunque nadie de tu equipo haya escrito la palabra Symfony en todo el año. Los parches salieron en cuatro ramas mantenidas, lo cual es un detalle generoso por parte de los mantenedores y también una forma educada de decir que nadie puede alegar que su versión era demasiado antigua para estar cubierta.

Voy a darle a la otra postura lo que merece, porque es un argumento real. Lo más probable es que tu composer.json ni siquiera mencione symfony/http-foundation. Laravel declara la restricción, tu lock file fija la versión exacta, y lanzar composer update cada vez que aparece una entrada en el blog de Symfony suena a la manera más rápida de meter un viernes por la tarde cambios que nadie ha revisado. Hay equipos que se han quemado así, y su prudencia viene de esas cicatrices. Dejar que el proveedor del framework haga la selección es un reparto del trabajo razonable para un equipo de tres personas.

Aun así, te cuento por qué acabo en el otro lado. Las versiones de parche dentro de una línea menor de Symfony siguen una promesa estricta de compatibilidad hacia atrás, así que el riesgo de actualizar dentro del rango que Laravel ya permite es pequeño, y el lock file te deja ver con un diff qué paquetes se han movido exactamente antes de que nada llegue a producción. Lo caro es esperar. La restricción de Laravel ya admite la versión corregida; lo único que separa tus servidores del parche es que nadie ha ejecutado el comando. Un aviso de seguridad que pasa tres semanas sin aplicarse porque el equipo esperaba una señal que nunca iba a llegar es justo como los fallos corrientes acaban convertidos en informes de incidentes.

Las correcciones que no son de seguridad lo demuestran de forma más discreta. Una de ellas corrigió un desfase en el componente Clock en torno a los cambios de horario de verano. Parece una curiosidad hasta que recuerdas que gran parte de Europa atrasa los relojes dentro de una semana, el 25 de octubre, y que en algún sitio hay una tarea programada a punto de ejecutarse a las 02:30 dos veces, o ninguna. Otra arregló cómo BrowserKit lee las rutas de las cookies, que es el tipo de cosa que vuelve inestable un test de integración para un desarrollador y lo deja en verde para todos los demás. Nada de esto aparecerá en unas notas de versión de Laravel, porque desde el punto de vista de Laravel no ha cambiado nada.

Así que mi postura práctica es esta. Suscríbete al feed del blog de Symfony, o al menos a los avisos de seguridad. Ejecuta composer audit en la CI para que una vulnerabilidad conocida rompa una build en lugar de esperar a que alguien se dé cuenta. Y cuando salga una ronda de parches, lanza un composer update symfony/* acotado en una rama, lee el diff del lock, deja que la batería de tests lo mastique y fusiona. En un proyecto sano son veinte minutos, y la mayor parte se va en esperar a PHPUnit. A los desarrolladores de Go les gusta bromear con que su biblioteca estándar es su framework; nosotros tenemos algo parecido gratis, mantenido por gente que sigue portando correcciones a una línea 6.4 que la mayoría de proveedores habría abandonado hace tiempo.

También hay aquí una pequeña cuestión cultural. Laravel y Symfony se presentan a menudo como rivales en las barras de las conferencias, y el composer.lock lo desmiente sin hacer ruido. El trabajo que mantiene estable a uno mantiene estable al otro, y tratar el mantenimiento de upstream como noticias ajenas es perderse la mitad de lo que protege a tus usuarios. Saber de dónde viene tu clase Request no es traicionar a tu framework. Es, sencillamente, ser preciso.

Lo que de verdad me gustaría saber de ti: ¿cómo gestiona hoy tu equipo los parches de upstream? ¿Actualizáis los componentes de Symfony a su propio ritmo con algo como Renovate o Dependabot, o esperáis a que una versión de Laravel los traiga, y alguna de las dos opciones os ha dado un disgusto en producción?