La escalera de la confianza

¿Snap? ¿Flatpak? Las nuevas aproximaciones al siempre deseado formato universal del instalador de aplicaciones para las distribuciones GNU / Linux están dando mucho que hablar en estos días. ¿Pero cuáles son realmente sus virtudes y defectos, sus ventajas y desventajas, sus pros y sus contras?

No tengo intención de repetirme hablando de los paquetes Snap, si no has pasado por aquí antes, te recomiendo que le des un vistazo a Snap: vientos de cambio. Charlemos pues de la especificación Flatpak.

Los paquetes Flatpak hasta hace muy poco eran conocidos con el nombre de XDA-APPS y aunque de seguro tenían impresionantes (supongo) avances, no tenían una aplicación práctica. ¿La razón? Alegando seguridad usaban como dependencia fundamental al futuro servidor gráfico Wayland. Como todos sabemos Wayland – Weston puede ser una maravilla (y con toda seguridad terminará por convertirse en el estándar) pero hasta el presente no es usado por absolutamente ninguna distribución; eso sí, algunas pocas permiten iniciar una sesión “experimental” con Wayland. Fedora por supuesto y recuerdo que KaOS también, seguramente hay mas pero no guardo memoria de otras.

Wayland no puede (ni debe) convertirse en el servidor gráfico de las distribuciones hasta que no se soluciones algunas “minucias”. Por ejemplo que existan controladores (drivers) para las tarjetas de vídeo; Hoy por hoy solamente los controladores libres para AMD y para nVidia pueden usarse (más o menos), y como ya sabemos (desafortunadamente) dejan mucho que desear. Otra pequeñez es que los escritorios (los Desktop Manager y los Window Manager) lo soporten; hasta donde sabemos solamente Gnome y Enlightement afirman hacerlo en forma completa, Plasma (KDE) va en camino y nada mas. Ni una palabra de todos los demás. Ni Xfce, ni Openbox, ni LXDE – LXQt, ni de ningún otro, por supuesto nada de Unity. Y en tercer lugar que al menos las aplicaciones “mayores”, esas que son esenciales lo hagan también: Navegadores, suites de oficina, clientes de correo, reproductores y un sinfín de esos programas que los usuarios de un sistema operativo casualmente usamos todos los días. En resumidas cuentas Wayland sigue tan lejos de la inmensa mayoría de los usuarios como el día que se anunció.

Todo esto viene al cuento porque a partir de que Canonical presentó sus paquetes Snap, desde algunos frentes se lanzaron ataques a la forma en que Snapy trabaja. El mas conocido es un artículo de Mattew Garret, en el que sostiene que los Snap son inseguros (vale la pena leer el artículo, pero mucho más los comentarios donde “le dieron una pasada” al autor). El motivo es que los Snap trabajan sobre el viejo Xorg y este es inseguro. ¡Por supuesto que lo es! Y hemos vivido todos los años del mundo con él sin sufrir demasiado.

Como esto no funcionó, de hecho (a mi parecer) fue el impulso final que necesitaban los Snap, los XDA-APP cambiaron de nombre al actual Flatpak y dieron un muy notable giro de 180 grados a sus intenciones y como no: ahora trabajan sobre el “odiado e inseguro” Xorg. Por ahí he leído y escuchado que todo es parte de la “guerra comercial” entre Canonical y Red Hat ya que el programador principal de los Flatpak es un ingeniero de la empresa del sombrero rojo. Yo no lo sé y en realidad no me importa; como usuario del montón solamente me importa poder discernir que sería lo mas conveniente para instalar en el caso de que requiriera un paquete autocontenido (más allá de andar de curioso).

Con lo anterior en mente hagamos un recuento de las principales diferencias entre ambas especificaciones. En primer lugar los paquetes Flatpak son esencialmente para usarse en un sistema operativo de escritorio y no tienen sentido en los servidores, a diferencia de los Snaps que pueden ser usados en cualquier tipo de instalación. Esto porque los Flatpak requieren de un Runtime (el del DM que sea el nativo de la aplicación en particular).

Vale la pena que me detenga a explicar con mas detalle de que se trata todo esto en beneficio de la claridad. Como sabemos los escritorios para las distribuciones se crean a partir de un juego de bibliotecas de programación: GTK para Gnome y otras como Xfce y LXDE, ELF para Enlightement y Moksha y Qt para Plasma (KDE) y LXQt y RazorQt. Por razones de economía y de simplicidad muchas (realmente muchas) de las posibilidades y características de los escritorios quedan guardadas en un tipo especial de programa (runtime) que siempre se está ejecutando “en el fondo” y que provee acceso a las funciones del escritorio a las aplicaciones. Vamos algo similar a lo que hace Android con la máquina virtual de Java.

Con esto se pretende que los programas no necesiten incorporar todos los cientos de miles de líneas de código necesario para hacer las tareas mas simples en relación con su interacción con el escritorio donde se usen. Por esta razón hay programas para Gnome, para KDE, para Xfce, etc. Y cuando instalamos un programa de un escritorio “extranjero” arrastramos un montón de dependencias de ese “extraño” a nuestras máquinas. Así además del consumo de recursos propio del programa en cuestión siempre nos encontramos con que se gasta memoria y procesador para los runtimes, los puentes de comunicación entre ambos y otros programas auxiliares que se usen por parte tanto del escritorio dominante como del huésped.

Desde luego que también existen programas agnósticos al escritorio, muy notablemente toda esa pléyade de aplicaciones muy antiguas que solo usan a Xorg y un creciente número de programas que solamente usan Qt (con el correspondiente runtime de Qt). Y aún hay otras que usan otros toolkits diferentes.

Los Flatpak son un proyecto de Gnome, y por ello solamente están interesados en aplicaciones de escritorio. En cambio los Snap tienen su origen en una distribución y la empresa que la respalda (Ubuntu – Canonical) y su interés es permitir paquetes que se acomoden a toda la gama de soluciones que ofrecen, servidores incluidos.

Todo esto espero que te haya resultado informativo; vayamos pues a asuntos más importantes: Los paquetes Snap son completamente autocontenidos, es decir todo lo que requiere una aplicación debe quedar incluido dentro del paquete, de forma que sea independiente del entorno donde se use. Esto hace que (hasta ahora) los Snap sean enormes (aunque su gasto de recursos es menos oneroso de lo que podría intuirse). En cambio los Flatpak realizan instalaciones por separado de las diversas partes, empezando por los muy grandes runtime que se requieran. Si bien en principio (una instalación) nueva terminará por ser similar en tamaño a la de un Snap (dividida en partes pero equivalente), instalaciones posteriores de aplicaciones empaquetadas con Flatpak podrían resultar mucho menores en tamaño.

Para explicarlo con mayor claridad supongamos que se desea instalar 4 programas que usen el runtime 3.44 de Gnome en un escritorio basado en Gnome 3.56. El primero de los Flatpak deberá descargar el necesario runtime incluido de la versión 3.44, además de lo que requiera la propia aplicación, pero las instalaciones de los programas 2, 3 y 4 solamente descargarán sus partes exclusivas, es decir serán mas pequeñas. Si se hiciera lo mismo con Snaps las cuatro descargas vendrían acompañadas de la totalidad de lo que se necesita, es decir cada descarga a partir de la segunda será mucho mayor que su equivalente en Flatpak. Por supuesto hay que tener en claro que si cada uno de los programas usa un runtime de versiones diferentes no habrá ninguna diferencia entre ambos sistemas, al menos en lo que se refiere al runtime.

En teoría esta práctica de establecer dependencias por separado (a imitación del sistema actual) permitiría fragmentar los paquetes Flatpak en tantas partes como fuera necesario, por ejemplo para otras bibliotecas, de modo que instalaciones posteriores no necesitarán descargar todo de nuevo, otra vez a la inversa de los Snap. Y nuevamente esto solo sería cierto para los casos de programas con versiones “repetidas” e igual para versiones “diferentes”.

Visto desde las “tripas” de la computadora habría ahora muchos mas directorios con partes individuales que sería compartidos para su uso por diferentes paquetes Flatpak en oposición a un número menor por los que usarían los Snap que no comparten absolutamente nada con otros paquetes Snap.

Entendido así y fuera de instalaciones sin ambiente gráfico los paquetes Flatpak aparentan ser mas convenientes. ¡Pero hay de mí, no lo veo así! Tengo la sospecha que se abre un hueco en la fiabilidad y en la seguridad al preferir Flatpak a Snap. ¡Voy a ser muy cauteloso! En primer lugar porque ambos proyectos están en pleno desarrollo, para decirlo con franqueza están en su primera infancia y muchas cosas pueden cambiar de la noche a la mañana. En segundo término porque este gatito solamente es un mirón y no está a la altura intelectual de los grandes programadores.

Compartir partes suena muy bien, de hecho es algo muy similar a lo que tenemos hoy en cualquier distribución. Pero la diferencia estriba en que en el sistema actual son los empaquetadores de cada distribución los que se encargan de poner esas piezas de programación adicionales (dependencias) en el sistema operativo y los programadores de aplicaciones solamente llaman a las dependencias necesarias. No son ellos quienes las instalan. Hoy en día esto ha llevado a que ninguna distro (ni siquiera las RR extremas) sean capaces de soportar todos los programas, por el simple hecho que una aplicación está construida para usar una X versión de XYZ partes del sistema operativo. El sistema a veces falla porque se requieren versiones mas nuevas que las que tiene el SO y a veces por la razón inversa.

Los Flatpak permiten (en teoría) que un programador use una biblioteca de la versión de su preferencia, llamémosla A.0001. Pero por desgracia los programadores (aunque a veces cueste aceptarlo) son humanos. Imaginemos otro programador que usa la misma biblioteca para su aplicación Flatpak, pero inadvertidamente es ligeramente diferente, por ejemplo se compiló con alguna diferencia o en realidad no puso suficiente atención y está usando la versión A.0001a. Ahora supongamos que se instalan ambos paquetes y la biblioteca que dependencia esté nombrada en como A.0001 para los dos paquetes: existe una posibilidad que el paquete Flatpak que depende de A.0001a, no trabaje adecuadamente porque ya se instaló previamente la versión A.0001, o al revés dependiendo de cual de los paquetes se instale en primer lugar. ¿Suena mal verdad? Imaginemos esto ahora multiplicado no tengo idea por cuantas posibilidades de aplicaciones distintas.

Puede ser obviamente peor. Digamos que la primera que se instaló en realidad es una versión con alguna incompatibilidad fundamental. A partir de ese punto todos los paquetes que usen esa dependencia fallaran de alguna manera y los pobres usuarios (y los programadores) podrían inútilmente quebrarse la cabeza tratando de encontrar una aguja en un pajar.

Si hasta ahora no me cuadran las números, hay que ir un paso más allá y suponer lo peor: Código malicioso. ¿Qué sucede si en esas dependencias se introduce código malicioso? Uno que deseé poner el sistema en entredicho, seguramente no se conformará con alterar una sola dependencia, probablemente lo haga en muchas de forma que algunas de ellas sea usada por otros paquetes Flatpak. En el peor de los casos su paquete será el primero y todos los subsecuentes quedarán irremediablemente contaminados.

¿Pueden los paquetes Snap sufrir contaminaciones encadenadas? Definitivamente no. El Snap malicioso no dejará de serlo, pero no podrá expandir su daño a otras aplicaciones. Por mucho que se hable de las vulnerabilidades de Xorg, no son las únicas que puede sufrir un sistema operativo. Seguramente son las más rentables en términos de robo de información o de intrusión de publicidad, pero de ninguna manera solamente se me ocurre este método para exprimir al pobre usuario.

El sistema de paquetes actual trabaja como una escalera de la confianza: Cada empaquetador verifica que lo que está poniendo en el sistema operativo esté libre de pecado, pero hace la (correcta) suposición que las dependencias son a su vez verificadas por otros empaquetadores, y así hasta llegar a la dependencia de mayor orden, es decir cada uno se apoya en un escalón de confianza y no tiene cada uno de ellos que verificar todos los escalones previos para ver si todo en la escalera está correcto.

Por el contrario los paquetes autocontenidos tipo Flatpak y Snap dejan toda esa responsabilidad a los creadores del paquete, a los que en el mundo real ninguna distribución podrá verificar con certeza absoluta. Ambos tipos de paquetes deben ir firmados, es decir se debe tratar de un programador de confianza. ¿Pero no vemos este mismo sistema en las tiendas de Android, iOS y W$? y ¿Acaso no hay ahí malware?

Esto sin duda es el argumento principal de todos aquellos que se oponen a cambiar el sistema de dependencias actual. Como se puede leer en cualquier foro, y en la documentación de cualquier distro, lo primero que se recomienda es no instalar paquetes que provengan de fuera de los repositorios oficiales: Se rompe la escalera de la confianza.

Obviamente la solución a estos problemas es la misma de siempre: No descargar e instalar nada desde fuera de los sitios de confianza. ¿Pero cuales serán los sitios de confianza? La gran cualidad de los paquetes autocontenidos es que ya no requieren la intervención de la distribución, que podría tener o no un repositorio para este tipo de paquetes. La “gracia” de esta forma de distribución es que libera a los programadores de la tarea de empaquetar en los N formatos que hay en las distribuciones y aunque nadie lo mencione a voz en cuello. ¡También los libera de los empaquetadores y de los repositorios!

Así, si como se espera, esta nueva forma de distribuir software genera un cambio importante en el posicionamiento de las distribuciones y con ello comienzan a poner las plantas en las playas de nuestros sistemas operativos los grandes editores de software, estaremos ante el mismo panorama que se vive hoy en W$ o en Android. Tiendas que no están 100% libres de software malicioso y usuarios que solamente se atienen a ellas en la medida que satisfagan sus necesidades.

De hecho en medida muy pequeña ya ocurre hoy. Como participante en los foros de soporte técnico, de cuando en cuando me encuentro con usuarios que descargaron esto o aquello de lugares variopintos. ¡A veces incluso la propia distribución!

Creo que aún en el hipotético caso que las distribuciones se pusieran de acuerdo para administrar, dirigir y mantener un único centro de paquetes autocontenidos (sueños guajiros mios) no sería posible evitar que se colara software malicioso o simplemente defectuoso, ni al repo ni mucho menos a las instalaciones individuales.

Hoy al parecer estamos de acuerdo en que a pesar de sus bondades el sistema de dependencias bajo ciertas circunstancias representa un lastre para la expansión de las distribuciones en el mundo. Pero quedará en cada quién escoger que tipo de paquete autocontenido es preferible usar. ¿Tú por cuál te inclinas?

Anuncios

2 pensamientos en “La escalera de la confianza

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s