Reprepro export no pudo encontrar la clave de firma

Tenemos un repositorio Debian privado que fue configurado hace años por un administrador del sistema anterior. Los paquetes fueron firmados por la clave anterior, 7610DDDE (que tuve que revocar), como se muestra aquí para el usuario root en el servidor de repositorios.

# gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub   1024D/2D230C5F 2006-01-03 [expired: 2007-02-07]
uid                  Debian Archive Automatic Signing Key (2006)  <ftpmaster@debian.org>

pub   1024D/7610DDDE 2006-03-03 [revoked: 2016-03-31]
uid                  Archive Maintainer <root@xxxxxxxxxx.com>

pub   4096R/DD219672 2016-04-18
uid                  Archive Maintainer <root@xxxxxxxxxx.com>

Todos los comandos a continuación son como usuario root. Modifiqué el archivo de repositorio / conf / distribuciones para usar la nueva subclave que creé explícitamente para firmar:

Architectures: i386 amd64 source
Codename: unstable
Components: main
...
SignWith: DD219672

Pero cuando uso dput para actualizar un paquete obtengo

Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!
This means that from outside your repository will still look like before (and
should still work if this old state worked), but the changes intended with this
call will not be visible until you call export directly (via reprepro export)

Y cuando ejecuto reprepro export directamente obtengo:

# reprepro -V export unstable
Exporting unstable...
 generating main/Contents-i386...
 generating main/Contents-amd64...
Could not find any key matching 'DD219672'!
ERROR: Could not finish exporting 'unstable'!

Busqué en Google y encontré un par de subprocesos antiguos que indicaban un posible problema con reprepro para encontrar el directorio gnupg adecuado ... así que probé esto con los mismos resultados anteriores:

# GNUPGHOME=/root/.gnupg reprepro -V export unstable

Un subproceso sugirió probar la clave firmando un archivo ficticio que parecía funcionar bien ... al menos no informó errores y terminé con un archivo bla.gpg de 576 bytes después de que se terminó.

# touch bla
# gpg -u DD219672 --sign bla

La página de manual de reprepro también sugiere "Si hay problemas con la firma, puede probar gpg --list-secret-keys value para ver cómo gpg podría interpretar el valor. Si ese comando no enumera ninguna clave o varias, intente encontrar algún otro valor (como el keyid), que gpg puede asociar más fácilmente con una clave única ". Así que lo comprobé también y obtuve:

# gpg --list-secret-keys DD219672
sec   4096R/DD219672 2016-04-18
uid                  Archive Maintainer <root@xxxxxxxxxx.com>

Y finalmente pude ponerme en contacto con el administrador del sistema que primero configuró nuestros repros y sugirió probar una clave sin una frase de contraseña. Así que generé una nueva clave de firma, DD219672, la publiqué, volví a seguir los pasos anteriores pero con el mismo resultado.

Hoy, después de leer y estudiar más páginas de manual y notar que pgp-agent se inicia automáticamente cuando ejecuto reprepro, decidí perseguirlo por un tiempo.

Agregué un gpg-agent.conf con

debug-level 7
log-file    /root/gpg.agent.log
debug-all

Y puedo ver en el registro que gpg-agent no encuentra las claves

2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK Pleased to meet you, process 18903
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- RESET
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttyname=/dev/pts/0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION ttytype=xterm-256color
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- GETINFO version
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> D 2.1.11
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION allow-pinentry-notify
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- OPTION agent-awareness=2.1.0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> OK
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- AGENT_ID
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67109139 Unknown IPC command <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- HAVEKEY C2C5C59E5E90830F314ABB66997CCFAACC5DEA2F 416E8A33354912FF4843D52AAAD43FBF206252D9 8CE77065EA6F3818A4975072C8341F32CB7B0EF0
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67108881 No secret key <GPG Agent>
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- [eof]

Hasta ahora no he podido averiguar dónde gpg-agent encuentra las claves que enumera en HAVKEY y cómo apuntarlo en la dirección correcta para encontrar la nueva clave, DD219672, para firmar nuestros paquetes actualizados.

Tuve el mismo problema, y ​​después de mucha frustración finalmente rastreé lo que estaba pasando.

La repreproherramienta usa gpgme, que se basa en gnupg2. Un lanzamiento reciente de eso cambió la forma en que se maneja el llavero secreto: https://www.gnupg.org/faq/whats-new-in-2.1.html

gpg solía mantener los pares de claves públicas en dos archivos: pubring.gpgy secring.gpg... Con GnuPG 2.1 esto cambió ... Para facilitar la migración al método sin seguridad, gpg detecta la presencia de ay secring.gpgconvierte las claves sobre la marcha al almacén de claves de gpg-agent (este es el private-keys-v1.ddirectorio debajo del directorio de inicio de GnuPG ( ~/.gnupg)). Esto se hace solo una vez y secring.gpggpg ya no toca un existente . Esto permite la coexistencia de versiones anteriores de GnuPG con GnuPG 2.1. Sin embargo, cualquier cambio en las claves privadas usando el nuevo gpg no aparecerá cuando se usen versiones anteriores a 2.1 de GnuPG y viceversa.

Por lo tanto, si crea una nueva clave con gpg, gpg2 no la verá, y viceversa.

Solución rápida que funcionó para mí:

gpg --export-secret-keys | gpg2 --import -

Y si necesita ir hacia otro lado, por supuesto:

gpg2 --export-secret-keys | gpg --import -

Dependiendo de su configuración, es posible que también desee / necesite agregar --export-secret-subkeys

Después de hacer lo anterior, repreprofuncionó correctamente con mi nueva clave.

Para mí, el problema era que generaba claves como usuario y ejecutaba reprepro como root .

Lo que sucedió fue que las claves que genero "sin sudo" se agregan a mi local pubring.gpg. Cuando ejecuto sudo reprepro ...lo ejecuto como root y, por lo tanto, intenta encontrar la clave en la raíz pubring.gpgy, obviamente, no encuentra una.

La solución fue ejecutar todos los gpgcomandos como root (eq. sudo -iY luego gpg --gen-key). Asegúrate de que cuando corras sudo gpg --list-keysveas las teclas deseadas y la línea /root/.gnupg/pubring.gpg.

¡Espero que ayude!