1. Permitir la carga asíncrona de contenidos en el cliente mediante la etiqueta {% render %} de Twig (ver PR #2865) se ha propuesto mediante una pull request la posibilidad de añadir soporte para cargar trozos de página de forma asíncrona mediante JavaScript. Se decide que la idea es buena, pero la implementación no. El problema es que se está reinventando la rueda, ya que existe una tecnología buena y probada que hace esto muy bien: hinclude.js. Se trata del equivalente de ESI para la parte del cliente. Se decide probar la integración de hinclude.js dentro del core de Symfony2. Si el resultado es bueno y no ensucia demasiado su código o las plantillas, se incorporará. Ver PR #2903 para conocer los detalles de la integración.

2. Añadir los métodos Kernel::terminate() y HttpKernel::terminate() para ejecutar código después de enviar la respuesta al usuario (ver PR #2791) la propuesta se acepta sin mucha discusión, ya que se considera algo realmente útil. No es algo que pueda sustituir a Gearman o RabbitMQ, pero puede venir muy bien en acciones puntuales con un procesamiento pesado o complejo y para la que no merece la pena o no se pueden instalar las herramientas anteriores.

3. Renombrado el método equals() a isSameUser() en la interfaz UserInterface (ver PR #2669) durante la reunión se volvió a discutir una vez más sobre el famoso método equals() de la interfaz UserInterface. El problema es que este nombre entra en conflicto con otras librerías (sobre todo con Propel) y según algunos no refleja realmente su propósito: este método no sólo comprueba que el usuario que te pasan sea el mismo, sino que también hay que comprobar si sigue siendo válido desde el punto de vista de la autenticación. Se proponen como alternativas:

• isSameUser()
• equalsUser()
• isSameAs()
• isSameAsValidAutenticatedUser()
• isStillConsideredAsValidForAuthentication()

Antes de que a alguien se le ocurrieran métodos con nombres todavía más largos, se propone eliminar el método equals() de la interfaz. ¿Por qué tienen los programadores que comprobar si el usuario es el mismo y sigue siendo válido? Que lo haga Symfony2 automáticamente y si quiero hacer cosas avanzadas, ya crearé una clase o implementaré una interfaz especial. Ver PR #2927 para los detalles de la nueva implementación.

Como siempre, también puedes leer los logs completos de la reunión para conocer los detalles discutidos para cada punto del orden del día.

El error es muy fácil de reproducir:

• El usuario accede al formulario que le permite modificar los datos de su perfil.
• El usuario cambia su username por cualquier otro que ya exista en la aplicación.
• Se le mostrará un error indicando que el nuevo username ya existe.
• El problema es que además, se acaba de cambiar al usuario por el nuevo username.
• El usuario puede acceder a la aplicación como si fuera el username indicado anteriormente.

$ php bin/vendors install

$ php app/console cache:clear

Fuente: Security Release: Symfony 2.0.6

Han pasado más de 10 meses desde ese anuncio y el código de Symfony ya ha sido exhaustivamente auditado. Las buenas noticias son que el código original era tan bueno que la empresa SektionEins encargada de la auditoría sólo ha podido encontrar incidencias menores.

El blog oficial de Symfony publica el listado completo de errores encontrados y enlaces a los commits que los solucionan. Igualmente, el blog de Twig ha publicado el brevísimo listado con los dos errores encontrados en su auditoría.  Teniendo en cuenta que el total entre los dos proyectos son unas 15 incidencias y que el coste fueron 6.000 euros,  el bug sale a 400 euros (bastante barato si se compara con Mozilla y Google Chrome, que pagan hasta 3.000 dólares a quien descubra un error en su código).

Así que a la larga lista de razones para utilizar Symfony2, ya podemos añadir el título de ser probablemente el framework PHP más seguro que exista. Y si además de Symfony2 utilizas algún otro framework, no olvides preguntarles cuántas auditorías de seguridad independientes han realizado de su código fuente.

Fuente: Symfony2 Security Audit

Javier López, de la empresa Flai, desarrolló durante su ponencia el formulario de registro completo con Symfony2, mostró las posibilidades de personalización de la vista de los formularios, el componente de seguridad, la definición de firewalls y la creación de un sistema de login con los usuarios de la aplicación.

Presentación

Vídeo

Además, esta actualización será la última de la rama 1.3.x, por lo que es una buena idea actualizar tus proyectos a 1.4.x, que será mantenida hasta noviembre del año 2012.

Como siempre, para actualizar tu versión de Symfony:

• Si usas el sandbox, te lo tienes que bajar otra vez.
• Si lo has instalado mediante el archivo comprimido de Symfony, te lo tienes que bajar otra vez desde www.symfony-project.org/installation/1_3 o www.symfony-project.org/installation/1_4 y debes descomprimirlo en el mismo directorio dentro de tu proyecto.
• Si lo has instalado mediante PEAR, ejecuta el comando pear upgrade symfony/symfony-1.3.10 o pear upgrade symfony/symfony-1.4.10
• Si lo instalas mediante Subversion, ejecuta el comando svn checkout http://svn.symfony-project.com/tags/RELEASE_1_3_10/ o svn checkout http://svn.symfony-project.com/tags/RELEASE_1_4_10/

Independientemente de cómo lo actualices, no olvides borrar la caché de cada proyecto después de la actualización mediante los siguientes comandos:

Si utilizas Doctrine:

$ php symfony doctrine:build --all-classes
$ php symfony cache:clear

Si utilizas Propel:

$ php symfony propel:build --all-classes
$ php symfony cache:clear

Fuente: symfony 1.3.10 and 1.4.10: security releases

Ver presentación en Google Docs

Hoy se anuncia en el blog oficial de Symfony que la campaña se ha cerrado con un rotundo éxito, recaudando más de 9.500 euros en total. Gracias a la generosidad de la comunidad, se ha conseguido dinero suficiente para auditar el código de Symfony2, Twig y también el de Doctrine2.

Esta iniciativa es una buena demostración de los beneficios que se obtienen cuando diferentes proyectos colaboran entre sí:

• El proyecto Symfony se  ha beneficiado de contar con un ORM excelente llamado Doctrine 2 y que funciona en Symfony mejor que en cualquier otro framework. A cambio Doctrine 2 recibe de regalo una auditoría de seguridad en su código valorada en 4.500 euros.
• phpBB 4 se beneficia de Symfony2 al contar con un framework excelente para crear la próxima versión del software de gestión de foros de discusión. A cambio, Symfony ha recibido una generosa donación de 5.000 euros por parte de la empresa responsable de phpBB.

Ahora la presión recae sobre la empresa SektionEins, que se juega su prestigio auditando un código utilizando por cientos de miles de personas en todo el mundo.

Fuente: We’re secure! (or getting there)

Esta empresa especializada en seguridad informática realizará una auditoría de todo el código fuente del framework Symfony2 y del motor de plantillas Twig. Los análisis incluirán pruebas contra todos los tipos de ataques conocidos relacionados con los sitios web, incluyendo los famosos ataques XSS, CSRF y de inyección de código SQL.

El único problema es que las auditorías de este tipo son carísimas y por eso el proyecto Symfony solicita tu ayuda. En la página symfony-project.org/donate puedes realizar una donación económica en tu nombre o en el de tu empresa para colaborar a que Symfony2 sea el framework más seguro del mercado.

Nosotros ya hemos hecho nuestra pequeña aportación y desde aquí os animamos a que colaboréis si os es posible. También podéis tratar de convencer a vuestros jefes para que tu empresa haga una aportación.

Actualización 13 de enero: el blog oficial de Symfony ha publicado un artículo con los detalles de la solicitud de donaciones. Lo más relevante es que la auditoría les va a costar 6.000 euros. (Muchas gracias a todos los que nos habéis avisado a través de los comentarios)

La vulnerabilidad descubierta está relacionada con la forma en la que se guardan las plantillas en la cache. Los parámetros GET de la URL de la plantilla se utilizan para determinar el directorio en el que se guarda la plantilla.

El problema es que estos parámetros GET de la plantilla no se limpiaban antes de generar la ruta donde se guardará la plantilla. La consecuencia es que un atacante podría utilizar parámetros GET especialmente preparados para almacenar las plantillas en algún directorio por encima del directorio de la cache de la aplicación.

Como siempre, para actualizar tu versión de Symfony:

• Si usas el sandbox, te lo tienes que bajar otra vez.
• Si lo has instalado mediante el archivo comprimido de Symfony, te lo tienes que bajar otra vez desde www.symfony-project.org/installation/1_3 o www.symfony-project.org/installation/1_4 y debes descomprimirlo en el mismo directorio dentro de tu proyecto.
• Si lo has instalado mediante PEAR, ejecuta el comando pear upgrade symfony/symfony-1.3.6 o pear upgrade symfony/symfony-1.4.6
• Si lo instalas mediante Subversion, ejecuta el comando svn checkout http://svn.symfony-project.com/tags/RELEASE_1_3_6/ o svn checkout http://svn.symfony-project.com/tags/RELEASE_1_4_6/

Independientemente de cómo lo actualices, no olvides borrar la caché de cada proyecto después de la actualización mediante los siguientes comandos:

Si utilizas Doctrine:

$ php symfony doctrine:build --all-classes
$ php symfony cache:clear

Si utilizas Propel:

$ php symfony propel:build --all-classes
$ php symfony cache:clear

Fuente: Security Release: symfony 1.3.6 and 1.4.6

• Los formularios basados en Doctrine y Propel contenían un fallo de seguridad que permitía a un usuario actualizar el valor de un registro de la base de datos diferente al que muestra el formulario. El fallo se encontraba en los validadores generados por Symfony para las claves primarias.
• Se ha actualizado Propel a su versión 1.4.2 y la librería de pruebas lime a su versión 1.0.9.
• Ahora se puede utilizar la tarea doctrine:clean para borrar los formularios generados para los modelos en los que se ha deshabilitado la generación de formularios.
• La clases de los widgets de fecha y hora utilizan correctamente la opción id_format.

Como siempre, para actualizar tu versión de Symfony:

• Si usas el sandbox, te lo tienes que bajar otra vez.
• Si lo has instalado mediante el archivo comprimido de Symfony, te lo tienes que bajar otra vez desde www.symfony-project.org/installation/1_3 o www.symfony-project.org/installation/1_4 y debes descomprimirlo en el mismo directorio dentro de tu proyecto.
• Si lo has instalado mediante PEAR, ejecuta el comando pear upgrade symfony/symfony-1.3.5 opear upgrade symfony/symfony-1.4.5
• Si lo instalas mediante Subversion, ejecuta el comando svn checkout http://svn.symfony-project.com/tags/RELEASE_1_3_5/ o svn checkout http://svn.symfony-project.com/tags/RELEASE_1_4_5/

Independientemente de cómo lo actualices, no olvides borrar la caché de cada proyecto después de la actualización mediante los siguientes comandos:

Si utilizas Doctrine:

$ php symfony doctrine:build --all-classes
$ php symfony cache:clear

Si utilizas Propel:

$ php symfony propel:build --all-classes
$ php symfony cache:clear

Fuente: symfony 1.3.5 and 1.4.5