Mantenimiento Drupal: cuándo actualizar módulos y core

by Jorge Tutor //

Guía rápida para identificar cuándo debemos actualizar módulos y core de Drupal.

Cuando un equipo se hace cargo por primera vez del mantenimiento de un proyecto basado en Drupal surgen siempre las preguntas: ¿Cómo actualizo un proyecto Drupal? Y ¿cuándo debo actualizar un proyecto Drupal? Si bien es fácil encontrar respuesta para la primera pregunta surgen muchas dudas de la segunda que aclararemos en este artículo.

Porqué actualizar

Drupal es un CMS (¡tan potente como un framework!) basado en componentes: módulos, plantillas, librerías (Composer, JavaScript, ...), etc., que se montan en torno a un core (Drupal). Dichos componentes son susceptibles a mejoras tanto funcionales como correcciones de seguridad y fallos.

 La seguridad y estabilidad de tu proyecto Drupal es tan fuerte como el más débil de los componentes que lo conforman.

Listado de actualizaciones

Para conocer el listado de componentes pendientes de actualización puedes visitar la url /admin/reports/updates/update

Listado de actualizaciones

 

Tipos de actualizaciones

Actualizaciones de seguridad

Actualizaciones destinadas a corregir vulnerabilidades del código. Estas actualizaciones son imprescindibles acometerlas cuanto antes ya que implica un riesgo potencial que puede ser explotado de manera maliciosa.

Drupal cuenta con un equipo de seguridad que comprueba y corrige junto con los mantenedores de los diferentes módulos y del core las posibles vulnerabilidades que se van detectando. Esta corrección se realiza de forma privada, de forma que solo el equipo de seguridad y quien haya reportado el bug y los mantenedores del componente tienen acceso a la información de la vulnerabilidad. La razón es por seguridad: si se publicase este tipo de información antes de corregir la incidencia se estaría facilitando que usuarios maliciosos pudiesen aprovechar el fallo para realizar ataques antes de que haya una solución. Una vez hay corrección la nueva versión del software es publicada, así como ciertos detalles del problema.

La publicación corrección va acompañada  de los escenarios en los que es vulnerable (el fallo de seguridad permite un ataque) e insta a aquellos proyectos que se encuentran afectados a su actualización. Dado que desde este momento la incidencia es pública su actualización no debe demorarse ya que pueden surgir exploits automáticos en las semanas e incluso horas siguientes.

En muchas ocasiones no nos veremos afectados pero es altamente recomendable actualizar. Solamente se deberá postponer la actualización en caso de estar totalmente seguros de que no estamos afectados y la nueva actualización no es compatible con nuestro proyecto. En este último caso se debería estudiar si interesa esperar a la nueva versión, corregir con parche, etc.

Información sobre el riesgo de seguridad

Esta información se publica con un formato establecido muy compacto que permite ver fácilmente el riesgo que representa el fallo.

Views - Critical

Los campos de información son los siguientes:

  • Advisory ID: Nombre identificativo.

  • Project: nombre del proyecto afectado (core, nombre de módulo o plantilla).

  • Versión: Versión afectada.

  • Date: Fecha.

  • Security Risk: Nivel de gravedad sobre 25 según la tabla Security Risk Level.

  • Vulnerability: Resúmen de la vulnerabilidad.

Ejemplos

Cuándo se publican las actualizaciones de seguridad

El equipo de seguridad ha elegido los miércoles (mitad de semana) como el día para desplegar las nuevas correcciones, permitiendo a los equipos de desarrollo margen para actualizar en la misma semana. Es bastante común que los equipos de mantenimiento reserven unas horas los miércoles y jueves para acometer dichas actualizaciones.

Para estar informado en todo momento es recomendable apuntarse a la lista de correo de seguridad de Drupal. Para ello necesitaremos crear una cuenta en Drupal.org y suscribirnos en la sección My Newsletters al editar nuestra cuenta:

security_newsletter_1.png

 

También puedes estar informado siguiendo la cuenta de twitter drupalsecurity.

 

Componentes cubiertos por el equipo de seguridad

Seguramente hayas visto el siguiente mensaje:

This project is not covered by Drupal’s security advisory policy.

Las notificaciones de seguridad son generadas tan solo para versiones estables del código (Y.x-Z.0 o superior), excluyendo ramas de desarrollo como (-dev), alpha, beta o rc.

Los proyectos que no cuenta con una versión estable de su código no están cubiertos activamente por el equipo de seguridad de Drupal.org, de forma que has de tenerlo en cuenta a la hora de elegir un componente y recuerda que siempre puedes ayudar al mantenedor a publicar una versión estable del módulo. Puedes leer más sobre la política de seguridad de Drupal.

Qué incluye una actualización de seguridad

Drupal incorpora junto con las actualizaciones de seguridad mejoras y cambios en el código. Si necesitas aplicar de forma rápida la corrección de seguridad y quieres postponer la actualización del componente completo, usualmente en la issue de seguridad se provee un parche a aplicar para corregir el error específico. Recuerda que aplicar parches de seguridad es algo que debe realizarse de manera provisional ya que lo recomendable es instalar la actualización completa. 

    Actualizaciones de nuevas versiones

    Son actualizaciones evolutivas que mejoran la estabilidad, agregan funcionalidad o refactorizaciones partes del código.  Estas actualizaciones no implican un riesgo de seguridad. Es una buena práctica tener el código actualizado ya que pueden corregir errores que estamos sufriendo y favorecemos la mantenabilidad del proyecto a medio plazo: compatibilidad entre componentes, rendimiento, compatibilidad versiones de PHP, etc.

    Ejemplos

    Cambios de versión o actualizaciones mayores

    Tenemos que tener un cuidado especial con los cambios de versiones. En Drupal algunos de los módulos contribuidos pueden tener cambios mayores de cara al código del módulo, esto se indica mediante cambio en versión. Por ejemplo: 7.x-2.x -> 7.x-3.x. 

    Un cambio de versión mayor puede perder la compatibilidad con módulos que dependen de él y tan sólo están preparados para la versión anterior. Además, incluyen cambios importantes en el módulo o plantilla (de ahí la razón del cambio de versión mayor), por lo que hay que revisar especialmente estas actualizaciones antes de aplicarlas.

    Esta es una de las situaciones en las que el uso de Behavior Driven Development (BDD) nos ayuda enormemente: si todos los tests se ejecutan sin problemas sabremos que al menos todos los comportamientos que los tests han probado siguen funcionado correctamente.
     

      Resúmen: Cuándo actualizar

      • Las actualizaciones de seguridad son necesario desplegarlas en cuanto sea posible, pues como se comenta, pueden implicar un grave riesgo de seguridad. 
      • Las actualizaciones que no son de seguridad deberían de estudiarse antes si son necesarias o no ya que estas actualizaciones pueden agregar simplemente una funcionalidad que no nos interesa o corregir ese molesto bug que arrastramos desde el inicio del proyecto.
         

      Drupal es un CMS seguro que activamente toma las medidas necesarias para que esto sea así, pero está en tus manos mantener tus proyectos actualizados y libres de errores con las herramientas que Drupal pone a tu alcance.

       

      Compartir