La página de manual de Ubuntu para apt-key incluye la siguiente nota con respecto a apt-key add:

Nota: en lugar de utilizar este comando, se debe colocar un llavero directamente en el directorio /etc/apt/trusted.gpg.d/ con un nombre descriptivo y "gpg" o "asc" como extensión de archivo.

No creo haber visto este consejo en ningún otro lado. La mayoría de los proyectos que alojan sus propios repositorios dicen que descarguen su archivo de clave y lo agreguen apt-key.

1. ¿Cuál es la motivación detrás de este consejo?
2. ¿Es esto un Ubuntu-ism, o se aplica a cualquier distribución basada en APT?

Esos proyectos tienen instrucciones obsoletas. Lo sé porque publico un repositorio de Debian y actualicé mis instrucciones cuando descubrí los cambios en Debian 9 APT. De hecho, esta parte del manual está desactualizada, ya que es el directorio incorrecto.

En realidad, esto no tiene que ver con los .ddirectorios y más con la prevención de una vulnerabilidad entre sitios en APT. El sistema anterior usaba archivos de llavero separados por conveniencia, pero ahora es una necesidad de seguridad; Su seguridad.

Esta es la vulnerabilidad. Considere dos editores de repositorios, A y B. En el mundo de Debian 8 y anteriores, las claves de ambos editores fueron en el llavero global único en las máquinas de los usuarios. Si el editor A pudiera de alguna manera hacer arreglos para reemplazar el sitio WWW del repositorio del editor B, entonces A podría publicar paquetes subversivos, firmados con la propia clave de A , que APT aceptaría e instalaría con gusto. Después de todo, la clave de A es de confianza a nivel mundial para todos los repositorios.

La mitigación es que los usuarios usen llaveros separados para editores individuales y hagan referencia a esos llaveros con Signed-Byconfiguraciones individuales en sus definiciones de repositorio. Específicamente, la clave del editor A solo se usa en el Signed-Byrepositorio A y la clave del editor B solo se usa en el Signed-Byrepositorio B. De esta manera, si el editor A suplanta el repositorio del editor B, APT no aceptará los paquetes subversivos ya que ellos y el El repositorio está firmado por la clave del editor A, no por la del editor B.

El /etc/apt/trusted.gpg.dmecanismo en cuestión es una casa a mitad de camino algo defectuosa de un viejo pobre hacia esto, desde 2005 más o menos, eso no es lo suficientemente bueno. Configura el llavero en un archivo separado, de modo que pueda ser empaquetado e instalado en un solo paso por un administrador de paquetes (o descargado con fetch/ curl/ wget) como cualquier otro archivo. (El administrador de paquetes maneja la prevención de que el paquete especial de este-este-es-mi-repositorio-llavero del editor A se instale sobre el editor B, de la manera normal que maneja los conflictos de archivos entre paquetes en general). Pero aún lo agrega al conjunto de claves eso es globalmente confiable para todos los repositorios. El mecanismo completo que existe ahora usa archivos de claves separados, no confiables globalmente /usr/share/keyrings/.

Mis instrucciones ya están ahí. ☺ Hay movimientos en marcha para mover los propios repositorios de Debian a este mecanismo, de modo que ya no usen claves confiables globalmente. Es posible que desee hablar con esos "la mayoría de los proyectos" que encontró. Después de todo, actualmente le están indicando que les entregue el acceso global a APT en su máquina.

Otras lecturas

• Daniel Kahn Gillmor (02/05/2017). Envíe las claves específicas de la versión por separado fuera de/etc/apt/trusted.gpg.d/ . Error de Debian # 861695.
• Daniel Kahn Gillmor (2017-07-27). Las sources.listentradas de Debian deben tener opciones firmadas que apunten a teclas específicas . Error de Debian # 877012.
• "Entrada de fuentes.lista" . Instrucciones para conectarse a un repositorio de terceros . Wiki de Debian. 2018.
• ¿Por qué no es un riesgo de seguridad agregar a sources.list?
• Debian 9, APT y "Error de GPG: ... InRelease: las siguientes firmas no eran válidas:"

apt-key deltoma el keyid, que es un hash sin sentido de la clave.

Es más simple si puede desinstalar claves usando un nombre significativo ... como un nombre de archivo.

Como dice JdeBP, esto funciona muy bien con archivos clave confiables que se instalan como parte de un paquete Debian. Creo que también puede ser mejor cuando has instalado manualmente un archivo de clave.

En el nuevo mecanismo que se encuentra actualmente en "prueba inicial", esto se simplifica aún más. Solo tiene que eliminar / deshabilitar una cosa: el repositorio (en sources.list / sources.list.d). Eso dejará de permitir automáticamente la clave configurada para ese repositorio (a menos que también haya sido utilizada por otro repositorio).

No sé cómo aprovechar el nuevo mecanismo de seguridad. Solo asumo que necesito confiar en alguien si uso su paquete. El proceso de instalación del paquete todavía se ejecuta como root:-).