El aviso del mantenedor, sus revisiones y las mitigaciones

Una mitigación reduce la posibilidad de que la falla se aproveche sin quitar el componente vulnerable: una opción de configuración, una regla de red, una función apagada. Sirve para ganar tiempo mientras se prepara el parche, y por eso necesita tres cosas que el parche no: una condición de validez (a qué versiones aplica), una fecha en que se retira y una forma de comprobar que sigue puesta después de un reinicio o un despliegue.

Una mitigación sin fecha de revisión se convierte en la solución definitiva por descuido, y una sin comprobación puede haberse perdido sin que nadie lo note.

Abre aviso-revision-1.txt y aviso-revision-2.txt. La revisión 1 decía qué versión corregía el problema; la revisión 2 matiza que esa no cubre un caso de configuración. Cuando dos revisiones dicen cosas distintas, vale la más reciente del mismo mantenedor, y el cambio se anota con su fecha para que nadie siga trabajando contra la revisión vieja.

La opción de configuración que sirve de mitigación solo existe desde cierta versión. Una aplicación afectada con una versión anterior no puede usarla, y tiene que actualizar o esperar a que se encuentre otra medida. Este es el tipo de aplicación que no puede quedar en la lista de «ya mitigadas» aunque alguien la haya revisado.

Cruza la versión mínima de la opción, en la revisión 1, con estado-de-las-aplicaciones.csv. Una aplicación que ni siquiera está en el rango afectado no cuenta.

Entre el 13 y el 14 de noviembre, tres aplicaciones se actualizaron a la 3.9.2, que era la corregida según la revisión 1. El sábado 14, la revisión 2 la deja dentro del rango afectado. Esas aplicaciones no se desinstalan ni se pierde nada: simplemente su ticket, que estaba bien cerrado contra el aviso de ayer, ya no lo está contra el de hoy.

Mira la columna version_el_14_nov y cuenta las aplicaciones que están en la versión 3.9.2.

El equipo se enfrenta a una disyuntiva: reabrir los tickets de las tres aplicaciones o dejarlos cerrados porque «ya se hizo lo que pedía el aviso». Lo segundo parece eficiente, pero lo que se cerró fue contra una revisión que ya no es la vigente. Reabrir no es un fallo del equipo: es el aviso que cambió, y el ticket debe decir contra qué revisión se verificó.