Next: Lanzamiento inicial, Previous: Using TeX and LaTeX, Up: GNU Guix [Contents][Index]
De manera ocasional, vulnerabilidades importantes de seguridad se descubren
en los paquetes de software y deben aplicarse parches. Las desarrolladoras
de Guix tratan de seguir las vulnerabilidades conocidas y aplicar parches
tan pronto como sea posible en la rama master
de Guix (todavía no
proporcionamos una rama “estable” que contenga únicamente actualizaciones
de seguridad). La herramienta guix lint
ayuda a las
desarrolladoras a encontrar versiones vulnerables de paquetes de software en
la distribución:
$ guix lint -c cve gnu/packages/base.scm:652:2: glibc@2.21: probablemente vulnerable a CVE-2015-1781, CVE-2015-7547 gnu/packages/gcc.scm:334:2: gcc@4.9.3: probablemente vulnerable a CVE-2015-5276 gnu/packages/image.scm:312:2: openjpeg@2.1.0: probablemente vulnerable a CVE-2016-1923, CVE-2016-1924 …
See Invocación de guix lint
, para más información.
Guix sigue una disciplina funcional de gestión de paquetes (see Introducción), lo que implica que, cuando se cambia un paquete, todos los paquetes que dependen de él deben ser reconstruidos. Esto puede ralentizar de manera significativa el despliegue de correcciones en paquetes básicos como libc o Bash, ya que básicamente la distribución al completo debe reconstruirse. El uso de binarios preconstruidos ayuda (see Sustituciones), pero el despliegue aún puede tomar más tiempo del deseado.
Para afrontar esto, Guix implementa injertos, un mecanismo que permite un rápido despliegue de actualizaciones críticas sin los costes asociados con una reconstrucción completa de la distribución. La idea es reconstruir únicamente el paquete que hace falta parchear, y entonces “injertarlo” en los paquetes explícitamente instalados por la usuaria y que previamente hacían referencia al paquete original. El coste de realizar un injerto es menor que una reconstrucción completa de la cadena de dependencias.
Por ejemplo, supongamos que es necesario incorporar una actualización de
seguridad en Bash. Las desarrolladoras de Guix proporcionarán una definición
de paquete para la versión “corregida” de Bash, digamos bash-fixed
,
de la manera habitual (see Definición de paquetes). Una vez hecho, la
definición original del paquete es aumentada con un campo replacement
que apunta al paquete que contiene la corrección del error:
(define bash
(package
(name "bash")
;; …
(replacement bash-fixed)))
De ahí en adelante, cualquier paquete que dependa directa o indirectamente
de Bash—como informa de ello guix gc --requisites
(see Invocación de guix gc
)—que se instale se “reescribe” automáticamente
para hacer referencia a bash-fixed
en vez de bash
. Este
proceso de injerto toma un tiempo proporcional al tamaño del paquete,
normalmente menos de un minuto para un paquete “medio” en una máquina
reciente. El injertado es recursivo: cuando una dependencia indirecta
requiere un injerto, el injerto se “propagará” hasta el paquete que la
usuaria esté instalando.
Actualmente, la longitud del nombre y la versión del injerto y aquella del
paquete que reemplaza (bash-fixed y bash en el ejemplo previo)
debe ser igual. Esta restricción viene principalmente del hecho de que el
injertado funciona mediante la aplicación de parches en archivos, incluyendo
archivos binarios, directamente. Otras restricciones pueden ser aplicables:
por ejemplo, durante la adición de un injerto a un paquete que proporciona
una biblioteca compartida, la biblioteca compartida y su reemplazo deben
tener el mismo SONAME
y deben ser compatibles a nivel binario.
La opción de línea de órdenes --no-grafts le permite anular voluntariamente el proceso de injerto (see --no-grafts). Por tanto, la orden:
guix build bash --no-grafts
devuelve el nombre de archivo del almacén de la versión original de Bash, mientras que:
guix build bash
devuelve el nombre de archivo del almacén de la versión “corregida”, reemplazo de Bash. Esto le permite distinguir entre las dos variantes de Bash.
Para verificar a qué Bash hace referencia su perfil al completo, puede
ejecutar (see Invocación de guix gc
):
guix gc -R $(readlink -f ~/.guix-profile) | grep bash
… y compare los nombres de archivo del almacén que obtendrá con los ejemplos previos. Del mismo modo, para una generación completa del sistema Guix:
guix gc -R $(guix system build my-config.scm) | grep bash
Por último, para comprobar qué versión de Bash están usando los procesos en
ejecución, puede usar la orden lsof
:
lsof | grep /gnu/store/.*bash
Next: Lanzamiento inicial, Previous: Using TeX and LaTeX, Up: GNU Guix [Contents][Index]