4/2, el nuevo ciclo de Ubuntu con el cual se busca reducir el tiempo para corregir vulnerabilidades en el kernel

Hace poco, el ingeniero encargado del empaquetado del kernel de Linux para Ubuntu, dio a conocer mediante un comunicado el cambio en el ciclo de actualizaciones del Kernel, con lo cual se planea implementar un nuevo ciclo de actualización del kernel.

Se menciona que el modelo del ciclo actual «SRU», es un modelo en el cual en un periodo de 3 semanas responde razonablemente, pero es propenso a interrupciones debido a CVE urgentes, solicitudes urgentes de clientes y regresiones encontradas en actualizaciones o durante pruebas.

Con el fin de mejorar la previsibilidad y la velocidad de la cadencia de lanzamiento de SRU de kernel, el equipo de kernel de Canonical está haciendo la transición del ciclo de 3 semanas a un nuevo ciclo de SRU de 4/2 kernel.

Es por ello que con el nuevo ciclo, cuyo nombre en código es «4/2», se busca abordar la formación de actualizaciones SU adicionales de los paquetes del núcleo (Actualización de seguridad), incluidas correcciones para problemas urgentes y vulnerabilidades marcadas como peligrosas y críticas.

De acuerdo con el nuevo esquema, las actualizaciones SRU (Stable Release Updates) de los paquetes del kernel se publicarán cada 4 semanas, transfiriendo las correcciones de las versiones correctivas del kernel de Linux. Dos semanas después del inicio del ciclo de generación de la próxima actualización de SRU, se publicará una actualización de SU por separado, que incluye correcciones solo para vulnerabilidades peligrosas y problemas importantes.

La preparación y prueba de las actualizaciones de SRU antes de la publicación llevará 4 semanas, y las actualizaciones de SU, 2 semanas. En las dos semanas restantes antes del final del ciclo general de SRU, las correcciones de vulnerabilidades peligrosas y problemas importantes se transferirán al próximo lanzamiento de la actualización de SRU.

Con el nuevo cronograma, nuestro objetivo es publicar correcciones para CVE críticos y altos y cualquier otra corrección crítica en una cadencia de 2 semanas. La actualización crítica/de seguridad «/2» que se publica además de un ciclo de actualización estable estándar publicado anteriormente es para garantizar que las soluciones críticas no se vean retrasadas por ningún problema o regresión en el nuevo ciclo estable «4».

Por lo tanto, las nuevas versiones de los paquetes del núcleo ahora se publicarán cada dos semanas, y la demora máxima en reparar vulnerabilidades peligrosas no excederá las dos semanas. Por ejemplo, el kernel 6.2 para Ubuntu 23.04 se empaquetará en el siguiente orden: se publicará una actualización de SRU en la semana que comienza el 7 de agosto con una transferencia de correcciones desde la rama anterior del kernel, se generará una actualización de SU con correcciones de vulnerabilidades en 21 de agosto, 4 de septiembre: actualización de SRU, 18 de septiembre: actualización de SU, etc.

Como tal, se menciona que se espera que el nuevo modelo «4/2» acelere la entrega de correcciones de vulnerabilidades a los usuarios, aumente la previsibilidad del proceso de desarrollo y sobre todo que garantice correcciones a vulnerabilidades críticas, ya que como se mencionó al inicio el modelo anterior, en el que se usaba un ciclo de desarrollo de tres semanas, hubo problemas con la velocidad de reparación de vulnerabilidades.

Los kernels OEM seguirán un calendario más flexible en cuanto a sus plazos para la aceptación de nuevos parches…

Con el nuevo calendario de ciclos de SRU, el equipo de kernel de Canonical espera ofrecer actualizaciones más predecibles con un tiempo de respuesta más rápido para las correcciones urgentes.

Si se seguía el cronograma, los usuarios tenían que esperar hasta tres semanas para que se solucionaran las vulnerabilidades no críticas. En caso de detección de problemas críticos, vulnerabilidades o regresiones, se generaban actualizaciones no programadas que interrumpían el proceso de preparación de la próxima actualización programada del kernel. Como resultado, las actualizaciones no programadas cambiaron el ciclo de la actualización planificada y retrasaron su publicación. En consecuencia, también se retrasó la entrega de soluciones para vulnerabilidades no críticas.

Finalmente, si estás interesado en poder conocer más al respecto sobre la nota, te invito a que visites el siguiente enlace.