Hace un tiempo que actualizaba mi Debian y no le daba importancia a algunos Warnings o advertencias relacionadas con el apt-key deprecado, y la verificación de firmas digitales de los paquetes. Eso no está bueno, así que hoy los eliminé, y les cuento lo que hice por si les sirve.
apt-key obsoleto, y sus efectos en Debian
Al intentar actualizar mi Debian, el apt update me devolvía algunas advertencias:
[...]
W: http://download.zerotier.com/debian/buster/dists/buster/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
W: https://packagecloud.io/slacktechnologies/slack/debian/dists/jessie/InRelease: Key is stored in legacy trusted.gpg keyring (/etc/apt/trusted.gpg), see the DEPRECATION section in apt-key(8) for details.
[...]
Estas advertencias indican que para algunos paquetes las claves estaban almacenadas en el anillo de claves principal del sistema (keyring trusted.gpg). Esto ya se considera deasctualizado, y la utilidad que lo administraba, apt-key, ya no debería utilizarse.
En mi caso, una de las claves correspondía a la herramienta de VPN Zerotier-One, y la otra a Slack (no me peguen, se que no es código abierto, es una de las pocas herramientas privativas que todavía uso 😐 ).
Les comento cómo hice para eliminar el warning de Zerotier ya que para cada repositorio el procedimiento es el mismo.
NOTA: en otra oportunidad, si les interesa, les comento cómo funciona la verificación de firmas digitales en APT, claves públicas y privadas, y el uso de GnuPG.
apt-key: solucionando el problema
Primero listamos las claves públicas del anillo de claves principal, o keyring trusted.gpg:
sudo apt-key list
Buscamos la clave de Zerotier:
Clave de Zerotier en el anillo de claves principal.
Del fingerprint de la clave (ese número hexadecimal largo de la segunda línea) extraemos los últimos 8 caracteres, en este caso: 23E52A61. Este código nos va a servir para exportar la clave desde el anillo de claves principal (administrado por la utilidad apt-key) y añadirlo como clave independiente al sistema.
Exportamos la clave de firma de los paquetes, y surque una pregunta: ¿dónde colocamos la clave nueva? Esto es, dónde buscará apt dicha clave para verificar la firma de los paquetes.
La respuesta puede variar, pero en general tenemos dos opciones. La más común: colocar las claves dentro del directorio de claves de confianza donde lee apt: /etc/apt/trusted.gpg.d/.
La otra opción: colocar la clave en cualquier directorio del sistema, preferentemente /etc/apt/keyrings/, y luego modificar el archivo de sources del repositorio en cuestión para indicarle dónde se encuentra la clave a utilizar para verificar la firma (Signed-by).
Personalmente suelo usar el directorio /etc/apt/trusted.gpg.d/ por comodidad, pero al final les muestro la otra forma por si a alguien le interesa, y de paso para que aprendamos cómo se hace, seguramente en algún momento tengamos que lidiar con esas configuraciones.
Al grano, exportamos la clave desde el keyring principal y la ponemos en el directorio nuevo. El número de identificación de la clave es el que extrajimos anteriormente, y el nombre de la clave es indistinto, debería ser algo que la identifique, en mi caso, zerotier.gpg.
Con esto ya podríamos hacer sudo apt update y tendríamos el problema del warning solucionado!
En mi caso tuve que realizar el mismo procedimiento para la clave del paquete Slack.
Finalmente, ahora ya se puede actualizar el sistema sin molestos warnings 😀
Signed-by: la otra opción
El paquete apt desde Debian 11 y Ubuntu 22.04 busca por defecto las claves de verificación de firma en el directorio /etc/apt/trusted.gpg.d/, el directorio que usamos en el ejemplo.
Si revisamos la documentación oficial: man apt-key, veremos algo como esto en la nota de deprecation:
man apt-key
Aquí detalla los directorios utilizados. Una opción es guardar las claves en cualquier directorio del sistema, convenientemente /etc/apt/keyrings, y luego indicar, en la configuración del repositorio, dónde se encuentra la clave para verificar la firma, ya que apt no busca por defecto en este directorio.
Si nuestra clave la guardamos aquí, por ejemplo, usando este comando:
Deberíamos modificar la línea de configuración del repositorio para indicar esta clave. En este caso particular mi configuración se encuentra en /etc/apt/sources.list.d/zerotier.list, y la configuración original es esta:
deb http://download.zerotier.com/debian/buster buster main
Debería modificarse de esta forma:
deb [arch=amd64 signed-by=/etc/apt/keyrings/zerotier.gpg] http://download.zerotier.com/debian/buster buster main
De esta forma, al actualizar el paquete, podrá verificar la firma correctamente.
Conclusiones: apt-key
En estos sencillos pasos hemos actualizado la forma en la que apt leía las claves públicas de un repositorio para verificar la firma de los paquetes.
Todo esto debido a que ha cambiado, desde hace algunos meses, la forma en la que Debian gestiona dichas firmas. Personalmente me gusta más cómo hace ahora, más simple e intuitivo.
De más está decir que deberíamos dejar de utilizar la utilidad apt-key. En el man de dicho comando menciona que ya está en su última versión, y que en las siguientes releases de Debian y Ubuntu ya no estará presente la utilidad.
Espero les sirva! Cualquier duda o comentario siempre es bienvenido!
¿Qué hace el comando type? El comando type es utilizado para obtener información sobre el tipo de un comando o función en Linux. Al ejecutarse se mostrará la ubicación del comando (archivo binario o incorporado Leer más…
Hoy analizaremos el significado del concepto de promedio de carga de procesos, o load average, en sistemas Linux… tres valores que vemos en la salida de comandos como uptime, top o htop. Respondiendo consultas de Leer más…
En este artículo haremos una breve reseña por las principales características de los sistemas de archivos, o filesystems, más utilizados en sistemas GNU/Linux, y cuales son las ventajas de cada uno. ext: sistemas de archivos Leer más…
