De backporting y actualización automática de versiones inseguras de WordPress

Por , actualizado en

Puede que no lo sepas, pero WordPress arrastra un problema desde hace ya un tiempo; cada que sale una versión nueva, se generan parches de seguridad para todas las versiones que viven en aquellos sitios cuyos dueños no quisieron actualizar por alguna razón en concreto, o bien por olvido; de esta manera, dichas versiones inseguras de WordPress, viejas y muy probablemente olvidadas, se mantienen hasta cierto punto, parchadas contra vulnerabilidades; a esto se le conoce como backporting. Genial, ¿no te parece?

La respuesta es que en parte si, y en parte no. Puede que falle miserablemente, pero como sea, intentaré explicar más a detalle:

¿Qué tiene de malo el backporting en el mundo de WordPress?

Esto que voy a mencionar es algo que muchos desconocen de esta plataforma que usan a diario, y que me parece hasta cierto punto algo desconcertante; WordPress es un proyecto que está donde está hoy en día gracias al trabajo de voluntarios, cientos de miles de ellos. Estos voluntarios son un recurso valiosísmo, y hablando de aquellos que están inmersos en los equipos que tienen que ver con el backporting, es un recurso que tiene que esforzarse en extremo para poder llevar a cabo esta actividad…esfuerzo que podría gastarse mejor en otras cosas, como en características más novedosas o quitar bugs, por mencionar un par de cosas.

Para que te des una idea de la magnitud del problema, cada que sale un parche nuevo relacionado con seguridad, hay que hacer parches para todas las versiones principales desde WordPress 3.7 (que es la primera versión que incluyó el sistema automatizado de instalación de liberaciones de seguridad), es decir, hay que hacer un proceso completo para poco más de 15 versiones que han salido desde entonces, 15 bocas a las que hay que darles de comer, y que consumen muchísimo.

Gráfica de distribución de versiones de WordPress
Tomado de wordpress.org

Y mira que WordPress 3.7 representa el 0.1% de todas las instalaciones; es decir, muchísimo trabajo para apenas unos cuantos – y digo “unos cuantos” pensando en el universo total de instalaciones de WordPress, no de un modo peyorativo.

Este modelo de backporting no está bien.

No debe continuar.

Con algo de suerte, intentaré dar mi punto de vista sobre porqué no debe continuar.

La política oficial de soporte de versiones de WordPress

Datos: directo del Codex de WordPress, este es un resumen del soporte a versiones:

  • La única versión para la que hay soporte…es la última. Sin más.
  • Versiones previas podrían o no obtener actualizaciones de seguridad.
  • No hay versión LTS (long-term support, soporte a largo plazo).
  • Se harán parches de seguridad para versiones anteriores a la actual cuando se pueda, y si se puede. No hay garantía alguna, ni marco de tiempo para hacer estos parches.
  • Cualquier versión anterior a la actual se considera como no segura.

Ahora empiezas a ver que lo que hacen los voluntarios es por demás generoso, ¿no te parece? pero seguir con este esquema sólo desgastará a los que trabajan en esto. Así que era cuestión de tiempo antes que alguien se preguntara si en verdad era esto necesario, y a partir de eso nació una idea para terminar con esta situación de los backports hasta tan atrás en el tiempo.

El plan para actualizar automáticamente versiones inseguras de WordPress

Pues bien, ya hay una idea más o menos concreta de como terminar con todo este relajo del backporting hacia versiones inseguras de WordPress. En esencia, el plan tiene como finalidad recortar el número de versiones a las que se hace backporting; para quedar claros: el backporting NO es malo ni desaparecerá, el problema radica en COMO SE HACE ACTUALMENTE. Ese es el problema real. Por lo tanto, se pretende actualizar de WordPress 3.7 a WordPress 4.7; eso nos dejaría con seis versiones a las que se haría backporting, lo cual significaría mucho, pero MUCHO menos trabajo para el equipo, y a la larga creo que el beneficio será para todos, pues como dije antes, ese valioso esfuerzo recuperado podrá ser dirigido hacia objetivos mucho más beneficiosos para la comunidad.

Si quieres consultar el plan completo, te invito a que visites el artículo en el blog de Make WordPress Core.

¿Pero como actualizarán esas versiones inseguras de WordPress?

Aquí es donde el plan se empieza a complicar:

Hasta ahora, el plan es hacerlo automáticamente gracias al mecanismo que existe desde WordPress 3.7, y se te dará la opción de salirte de esta ronda de actualizaciones…es decir, por default tu sitio con una versión insegura de WordPress estará dentro de los que se actualizarán a menos que explícitamente digas que NO querrás tal cosa, en vez que indiques que SI quieres de manera explícita. Obviamente, si tu instalación no tiene habilitadas actualizaciones de ningún tipo, entonces no ha nada que temer.

De nuevo: se hará a través de actualización automática, y necesitas decir que no quieres participar para que tu sitio no sea actualizado.

¿De quién es responsabilidad la actualización de un sitio web?

Muestra tres figuras haciendo los gestos de 'no escucho', 'no hablo' y 'no veo'

Yo creo que es del dueño del sitio; sin embargo, a todas luces a muchos no les importa: vamos, si funciona es que no necesita nada. Para muchos, un sitio es algo de encender y olvidarse de el. En la discusión de las actualizaciones automáticas sin preguntarle al dueño, alguien hizo una comparación con la situación siguiente:

Si alguien muere en la calle: ¿lo dejamos ahí tirado sólo porque no tuvo tiempo de acceder a que lo entierren?

Autor desconocido

Y la respuesta es que no, dependiendo del lugar en que se de una situación así, algún organismo que tenga que ver con la sanidad o el ayuntamiento tendrá que levantar el cadáver y en el peor de los casos irá a una fosa común. Y así podemos pensar en otros casos similares: un auto abandonado; una casa vieja que se convierte en peligro para los que pasan cerca; un niño maltratado por sus padres, por mencionar algunos.

Todos esos casos comparten algunas características…¿ves cuales son? una se repite: en todos ellos, un tercero tiene que decidir que hacer cuando el afectado se vuelve incompetente; valga la pena mencionar que ese tercero es un organismo o entidad con la autoridad suficiente para tomar una decisión al respecto: el ayuntamiento, algún organismo de gobierno relacionado con la familia, protección civil, etc.

En pocas palabras, tu sitio es tu responsabilidad, mientras no represente un problema para otros. Cuando lo sea, alguien más vendrá a tocar tu puerta y a hacerse cargo – y no de la manera más propia.

Así que, ¿quién se hará cargo de los sitios en cuestión?

WordPress al rescate de los sitios inseguros

Muestra a un policía con el logo de WordPress como cabeza y que usa  un ariete para tumbar una puerta

En el caso de los sitios abandonados, no hay tal instancia que dictamine qué hacer al respecto. Si tienes un sitio podrido, es tu problema. Algunos proveedores de alojamiento toman cartas en el asunto algunas veces, pero a menos que tu servicio sea gestionado, no harán nada así tu sitio haga estallar a los navegadores que lo visitan. Entonces, si el dueño no hace nada, ¿quién queda? la siguiente instancia en la cadena es WordPress mismo, el software, el equipo detrás de este, llámale como quieras, y que a fin de cuentas son los que se sienten en parte responsables por lo que está pasando en la actualidad con las versiones inseguras, y de ahí que venga la idea de proceder con la actualización automática. Yo creo que no es responsabilidad de ellos, y es lo que veo mal en todo este plan.

Y aquí es donde topamos con piedra: ¿hasta donde tiene autoridad la gente detrás de este maravilloso software que es WordPress para hacer algo así? digo, no todos los sitios con WordPress 3.7.x (o la versión que quieras anterior a 4.7) están abandonados…algunos puede ser que por alguna razón, por extraña que parezca, necesitaban quedarse así: piensa en una instalación multisitio de alguna universidad, algún organismo de investigadores con una instalación en una intranet, alguien que tenía alguna dependencia en un plugin, en fin, podemos pensar en muchos casos. ¿Es válido que de pronto, el software que has usado por años hace un cambio tan importante por si solo?

En lo personal creo que la idea no está mal, el como la implementarán, si.

Revisando el potencial de caos de las actualizaciones automáticas de versiones inseguras de WordPress

Muestra un cristal roto sobre un logotipo de WordPress

¿Se romperían muchos sitios de intentar esta actualización automática de versiones inseguras de WordPress?

Probablemente.

Seguramente.

Nadie puede decirlo con certeza; el plan es ir soltando poco a poco las actualizaciones, en una primera etapa se pretende actualizar el 2% de los sitios con WordPress 3.7 para ver si todo va bien o para echarse para atrás (el mecanismo de actualización automática puede hacer esto sin problemas) y revaluar la estrategia. Y si creemos en las cifras de Samuel Wood (Otto en los foros), hay unos 50,000-100,000 sitios con WordPress 3.7, quizás 200,000 en el caso más pesimista, así que al menos los sitios rotos no serían tantos, pero a decir verdad nadie puede asegurar nada en este caso.

Pero si puedo pensar sobre que problemas tendrán:

  • Plugins/temas viejos
  • Plugins/temas de paga
  • Versiones de PHP y MySQL anticuadas

Por sentido común, se antoja que la van a tener difícil. Honestamente no sé como NO van a haber sitios rotos.

¿Cómo le notificarán al dueño del sitio de la actualización automática que se hará?

Muestra varios contadores de notificaciones sin leer, pensando en las notificaciones por actualización automática de versiones inseguras de WordPress
¿Notificaciones? no necesitamos apestosas notificaciones…

Aquí tengo (yo y muchos) problemas con los métodos propuestos: ¿notificación en el dashboard? buena suerte con eso, a estas alturas el dueño ya recibió seis años de notificaciones, muy probablemente no ha visto ninguna. ¿Correo electrónico? mejor suerte con eso, la media de apertura de correo de la industria es de alrededor del 20%, y todos los que hemos enviado una campaña de correo electrónico sabemos que más bien anda en el 14% cuando andas de suerte y le rezas a los dioses. Honestamente no veo una forma eficiente de notificar a los “dueños” de dichos sitios, si es que todavía andan activos por ahí.

Yo creo que en esto van a tener que decidir fríamente, y como lo veo ya lo hicieron con su forma propuesta de un mecanismo (casilla de verificación seguramente) donde indiques que no quieres participar. Nadie o casi nadie lo verá, menos lo usarán.

¿Pero porqué es problema lo anterior? porque el mundo es un lugar diverso y lo que funciona aquí no funciona al otro lado del charco. Por ejemplo, en la Unión Europea esto de “salirse de la actualización automática” que quieren hacer no sirve como consentimiento, así de fácil. Tienes que dar consentimiento explícito.

Y aún así, creo que lo harán a como de lugar, a juzgar por los comentarios del equipo de WordPress.

Intermedio: mi humilde propuesta de notificación sobre la actualización automática

Muestra una balanza hecha con rocas, como metáfora de propuesta para actualización automática de versiones inseguras de WordPress

Así que podemos dar por sentado que los dueños de los sitios difícilmente verán una notificación en su panel de WordPress, creo que en eso coincidimos casi todos. Para ver esa notificación hay que entrar en dicho panel, cosa que muy probablemente los dueños de sitios inseguros no hacen, y aún más probablemente no hagan en el futuro.

Pero, ¿y que tal si la notificación no está en el interior, sino en el exterior?

Vamos, si están considerando (el equipo de wordpress.org) hacer algo rayando en lo bárbarico como actualizar un sitio sin permiso del dueño, bien podríamos llegar a un punto medio que podría funcionar más o menos así:

  1. Se lanza una actualización menor para versiones inseguras de WordPress que contiene la notificación en el sitio.
  2. Se toma uno de dos caminos:
    1. Si se quiere llamar la atención en serio del dueño, poner el sitio en modo de mantenimiento (con todo y estado HTTP 503), o
    2. Desplegar una notificación en la parte superior del sitio con algún mensaje alusivo a la próxima actualización.
  3. Se dan un número fijo de días para que el dueño tome el asunto en sus manos; 30 días me parecen suficientes; o lo actualiza o entra en su dashboard y se sale de la actualización automática , o desactiva todo tipo de actualización por código o plugin, en cualquiera de los casos de no actualizarse queda en manos de Jebús…o no hace absolutamente nada, y pasamos al punto 4.
  4. Si pasan los 30 días de gracia y no hace nada, muy probablemente es un sitio en total abandono; se procedería a llevar el plan de actualizaciones automáticas.

En este esquema se podría obtener una “aceptación” por parte del dueño, o bien este podría solucionar solo el problema de su sitio desactualizado. El dueño se enterará el mismo o alguien le dirá que ve algo raro en su sitio, y con algo de suerte haremos que voltee a ver su propiedad y haga algo al respecto. Ya si de plano no funciona, pues que se actualice automáticamente el sitio y que pase lo que tenga que pasar. La diferencia con el esquema propuesto por el equipo de WordPress.org es que se incrementaría la posibilidad de que el dueño del sitio vea la notificación y el proceso sea un poco más amigable, y quizás se reduciría la posibilidad de que al dueño le de un derrame cerebral por el (potencial) coraje. Sigue sin estar bien, sólo es un método “menos malo“.

Otra propuesta, la opción nuclear: fin de vida de versiones inseguras de WordPress

Muestra una imagen de un reloj de arena como metáfora de una política de fin de vida para versiones inseguras de WordPress

Recuerdan esa escena en la película “El día después de mañana” (vil churrazo, pero palomitera) cuando el personaje de Dennis Quaid explica el congelamiento mientras traza una raya que atraviesa un mapa de Estados Unidos por el centro y dice que evacuen a toda la gente que esté al sur de esa raya. Un oficial del ejército le pregunta “¿Y que pasará con la gente del norte?” a lo que responde “No lo lograrán.

Al igual que en la película, creo que muchos sitios están más allá de “ser salvados“.

La propuesta que creo debería hacerse y ya no es mía, viene de muchos otros que la han propuesto una y otra vez: establecer una política clara de fin de vida (EOL, end of life), así como una campaña de apoyo para tratar de concientizar a los usuarios sobre sus sitios y de porqué son su responsabilidad, y después de un tiempo si no hacen nada, el sitio no seguirá recibiendo actualizaciones. Tántán.

A veces hay que romper unos cuantos huevos para hacer un buen omelette. Y finalmente, en cualquier caso creo que no hay forma de que todos ganen. Habrá que hacer algún sacrificio.

¿Y los dueños de sitios podrían demandar por daños?

Este es un tema por demás espinoso. Y por supuesto (y que sirva como disclaimer) no soy un abogado ni estoy especializado en el tema.

En medio de todo esto veo a la GPL v2: muy en particular a sus puntos 11 y 12, repito, no hay garantías de ningún tipo y no hay responsabilidad de ninguna clase, y sobre todo, que el software se ofrece “como es“. El tema de las demandas y las disposiciones 11 y 12 de la GPL tampoco son tan blanco y negro: hasta donde sé, dichas disposiciones quedan sujetas a las leyes del lugar de origen.

Sin embargo, viendo la historia de WordPress, no es la primera ni última vez que se romperán sitios. En el pasado, se han caído o roto cuando salió el módulo de Health Check, o por Gutenberg, y otros casos más.

Si hubieron demandas, fueron pocas y dispersas. No veo nada distinto esta vez, quizás haya mucha gente molesta -y creo que la habrá- pero no pasará a mayores. No veo esto de la actualización enajenando a más gente que, digamos, Gutenberg, que me encanta por cierto, pero las cosas como son.

Ahora bien, hasta ahora hablé de usuarios, como tú o como yo, que tienen un sitio de pequeño a mediano, un blog, una tiendita online quizás; pero no hay que olvidarse de que WordPress se usa de muchas maneras, y para muestra un botón: WordPress se usa muchísimo en instituciones educativas de todos los niveles, desde un sitio personal de un investigador hasta grandes y complejas instalaciones multisitio que dan batería a cosas tan distintas como micrositios de facultades, clubes, grupos de alumnos, etc., y es en estos casos especiales donde puedo ver que habrá mucha gente molestia, y con justa razón.

Oportunidades, retos y enseñanzas derivados de la actualización de versiones inseguras

Como oportunidades veo las siguientes:

  1. Obviamente, trabajo para todos los que nos dedicamos a esto.
  2. Si la idea es que la base sean 6 versiones antes de la actual, ¿porqué no aprovechar para limpiar de basura el repositorio de plugins y de temas? si la idea es un esquema de mayor seguridad, ¿para que mantener plugins viejos que sólo fueron probados hasta una versión insegura? pues adiós de una vez, ya no tienen razón de estar ahí.
  3. Creo que es una oportunidad para todos los involucrados para ecualizar el lenguaje que los que trabajamos en esto y los usuarios de los sitios, en relación a WordPress y como funciona, a la GPL, y a otros temas que quizás sólo un grupo reducido conocemos (en comparación), pero que tienen impacto en millones.

En el apartado de retos:

  1. Uno importante: por ahora la meta es actualizar versiones inseguras hasta llegar a WordPress 4.7; pero después de eso WordPress 5.0 está a tiro de piedra; y si WordPress 5.x fue un shock para muchos que iban con las actualizaciones en orden, imagínate a alguien que viene repatriado desde WordPress 3.7 y se encuentra con Gutenberg…es como esas bromas en donde se mete una persona a un baño portátil, y cuando se encierra le construyen un set y cuando sale ve todo diferente…igual será aquí, y será otro movimiento que habrá que prever con cuidado.
  2. Un manejo sensible de tiempos para iniciar la educación sobre el proceso, para implementar el plan y para evaluar resultados. Ojalá que no se precipiten.

En el apartado de enseñanza, creo que la principal es que hace falta una cabeza en el mundo de WordPress, y me refiero muy en particular al Proyecto de Gobernanza de WordPress, pues todo esto de lo que he hablado sólo lo han decidido unos cuantos…y todos los millones de usuarios que tiene WordPress no tienen una representación real en todo este embrollo.

Hace falta el Proyecto de Governanza, y hace falta ya.

Comentarios finales

Por si no quedó claro: la actualización de versiones inseguras de WordPress se llevará a cabo, es la única certeza.

¿Estoy a favor o en contra? a favor de actualizar, en contra de la forma en que lo harán.

Lo que todavía no se sabe es una línea de tiempo precisa.

Pero si eres de los que tienen un sitio con un WordPress inseguro, ahora es buen momento de ir buscando asesoría de un profesional de WordPress para que te ayude a migrar tu sitio sin problemas, y no lo tenga que hacer un tercero (el equipo de WordPress.org) que, aunque tiene buenas intenciones, no se sentará a llorar si se rompe tu sitio.

Después de todo, tu sitio es TÚ responsabilidad.

Orlando Alonzo

Orlando es un ingeniero en sistemas de 45 años de edad, apasionado del desarrollo de software y con un cariño especial por WordPress. Le encantan los libros, la música, la fotografía, los cómics y es un AFOL. De último pero no menos, esposo y padre de dos trolls.

Deja un comentario

Hazlo con WordPress