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

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 clave y lo agreguen con apt-key .

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

Respuesta aceptada:

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

Esto no tiene nada que ver con .d directorios y más que ver 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 por seguridad; tu seguridad.

Esta es la vulnerabilidad. Considere dos publicadores de repositorios, A y B. En el mundo de Debian 8 y antes, las claves de ambos publicadores iban en el conjunto de claves único global en las máquinas de los usuarios. Si el editor A pudiera de alguna manera hacer arreglos para suplantar 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 confiable a nivel mundial para todos los repositorios.

La mitigación consiste en que los usuarios utilicen conjuntos de claves independientes para editores individuales , y para hacer referencia a esos llaveros con Signed-By individual configuración en sus definiciones de repositorio. Específicamente, la clave del editor A solo se usa en el Signed-By del repositorio A y la clave del editor B solo se usa en el Signed-By del repositorio B. De esta manera, si el editor A suplanta al repositorio del editor B, APT no aceptará los paquetes subversivos de él, ya que ellos y el repositorio están firmados por la clave del editor A y no por la del editor B.

El /etc/apt/trusted.gpg.d El mecanismo en cuestión es la casa intermedia algo defectuosa de un hombre pobre más viejo hacia esto, desde 2005 más o menos, que no es lo suficientemente bueno. Configura el conjunto de claves en un archivo separado, de modo que un administrador de paquetes puede empaquetarlo e instalarlo en un solo paso (o descargarlo con fetch /curl /wget ) como cualquier otro archivo. (El administrador de paquetes se encarga de evitar que el este-es-mi-repositorio-de-llaves especial del editor A paquete se instale sobre el editor B, de la manera normal en que maneja los conflictos de archivos entre paquetes en general). Pero aún así lo agrega al conjunto de claves en las que se confía globalmente para todos los repositorios. El mecanismo completo que existe ahora usa separado, no archivos de llavero de confianza mundial en /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 de confianza global. Es posible que desee hablar con la "mayoría de los proyectos" que encontró. Después de todo, actualmente le están dando instrucciones para que les entregue el acceso global a APT en su máquina.

Lecturas adicionales

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