Firmas gpg y apt / aptitude

Puede que alguna vez os hayáis encontrado con un mensaje parecido al siguiente al hacer un apt-get update o aptitude update después de añadir un nuevo repositorio a /etc/apt/sources.list

W: GPG error: http://pkg-voip.buildserver.net feisty Release: Las firmas siguientes no se pudieron verificar porque su llave pública no está disponible: NO_PUBKEY 2A5E3A5A52ABFCB1
W: Tal vez quiera ejecutar 'apt-get update' para corregir estos problemas

Se trata de un warning que nos avisa de que el archivo Release está firmado de forma que se pueda verificar el origen de los paquetes de ese repositorio usando GPG. Podemos por tanto asegurarnos de que los paquetes que instalamos son paquetes que ha subido el administrador del repositorio y que no han sido modificados por nadie más. Imaginaos qué ocurriría si un cracker lograra acceder a uno de los repositorios de vuestro sources.list y sustituyera los paquetes por otros de dudosas intenciones…

Podemos proceder a instalar los paquetes del nuevo repositorio sin ningún problema, dado que no se trata más que de un warning. Simplemente se nos avisará antes de instalar un paquete de dicho repositorio:

ADVERTENCIA: ¡se instalarán versiones no confiables de los siguientes paquetes!

Los paquetes no confiables pueden comprometer la seguridad de su sistema.
Debe proceder con la instalación solamente si tiene la
certeza de que es esto lo que desea hacer.

wengophone

¿Quiere ignorar esta advertencia y proceder de todas formas?
Para continuar, introduzca "Si"; para abortar, introduzca "No":

Sin embargo, es más conveniente aprovecharnos de esta característica, ya sea por nuestra seguridad, o para no encontrar el molesto aviso cada vez que actualicemos la lista de paquetes o intentemos instalar un paquete del repositorio.

Para manejar la lista de claves utilizadas por apt y aptitude se utiliza el comando apt-key que en realidad no es más que un script bash que utiliza gpg por debajo.

Para listar las claves que tenemos en este momento en nuestro keyring se utiliza el comando apt-key list

zootropo@genua:~$ sudo apt-key list
/etc/apt/trusted.gpg
——————–
pub 1024D/437D05B5 2004-09-12
uid Ubuntu Archive Automatic Signing Key
sub 2048g/79164387 2004-09-12
pub 1024D/FBB75451 2004-12-30
uid Ubuntu CD Image Automatic Signing Key
pub 1024D/81836EBF 2006-06-26
uid Treviño (3v1n0) uid Marco Trevisan uid Treviño Ubuntu Repository sub 4096g/EDD1E155 2006-06-26
sub 1024D/DD800CD9 2006-10-19
pub 1024D/937215FF 2006-06-01
uid Matti Lindell
sub 2048g/C1E5CE8D 2006-06-01
pub 1024R/1135D466 2005-08-22 [[caduca: 2010-08-21]]
uid Dennis Kaarsemaker (Package signing key)

Para añadir nuevas claves se utiliza apt-key add archivo o apt-key add - para que la clave se lea de la entrada estándar en lugar de hacerlo de un fichero.

El único problema es, ¿de dónde descargamos el archivo con la clave? No existe ninguna localización estándar, aunque a menudo en las instrucciones para utilizar el repositorio nos indicarán dónde encontrar dicha clave. Si no es así, nos queda el recurso de consultar a un servidor de llaves por la clave cuyo identificador es el que nos dieron en el warning. Para el repositorio de nuestro ejemplo:

zootropo@genua:~$ gpg –recv-key 2A5E3A5A52ABFCB1
gpg: solicitando clave 52ABFCB1 de hkp servidor subkeys.pgp.net
gpg: clave 52ABFCB1: clave pública “Build Server ” importada
gpg: no se encuentran claves totalmente fiables
gpg: Cantidad total procesada: 1
gpg: importadas: 1

Esto hará que la clave se importe en el keyring por defecto de GPG. Ahora podemos exportarla a un archivo:

gpg –export 2A5E3A5A52ABFCB1 > clave

e importarla en el keyring de apt / aptitude usando apt-key:

sudo apt-key add clave

O bien podemos exportarla e importarla en un solo paso:

gpg –export 2A5E3A5A52ABFCB1 | sudo apt-key add –

Comentarios
  1. Muchas gracias por la información.

    Esta es una de esas cosas que siempre me han pasado e intuía su solución, pero esta explicación me aclara todas las dudas.

    Responder

  2. […] último, las firmas GPG de los repositorios que las requieren, para el caso de que el gestor de paquetes se […]

    Responder

  3. […] último, las firmas GPG de los repositorios que las requieren, para el caso de que el gestor de paquetes se […]

    Responder

Deja un comentario