L'esportazione di Reprepro non è riuscita a trovare la chiave di firma

Abbiamo un repository debian privato che è stato creato anni fa da un amministratore di sistema precedente. I pacchetti sono stati firmati dalla chiave precedente, 7610DDDE (che ho dovuto revocare), come mostrato qui per l'utente root sul server repo.

# 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>

Tutti i comandi seguenti sono come utente root. Ho modificato il file repository / conf / distribututions per utilizzare la nuova sottochiave che ho creato esplicitamente per la firma:

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

Ma quando uso dput per aggiornare un pacchetto ottengo

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)

E quando eseguo direttamente l'esportazione reprepro ottengo:

# 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'!

Ho cercato su Google e ho trovato un paio di vecchi thread che indicavano un possibile problema con reprepro trovando la directory gnupg corretta ... quindi ho provato questo con gli stessi risultati sopra:

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

Un thread ha suggerito di provare la chiave firmando un file fittizio che sembrava funzionare bene ... almeno non ha riportato errori e alla fine ho finito con un file bla.gpg da 576 byte.

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

La pagina man reprepro suggerisce anche "Se ci sono problemi con la firma, puoi provare gpg --list-secret-keys value per vedere come gpg potrebbe interpretare il valore. Se quel comando non elenca alcuna chiave o più, prova a trovare qualche altro valore (come il keyid), che gpg può associare più facilmente a una chiave univoca ". Quindi ho controllato anche quello e ho ottenuto:

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

E finalmente sono stato in grado di mettermi in contatto con l'amministratore di sistema che ha impostato prima le nostre repliche e mi ha suggerito di provare una chiave senza passphrase. Così ho generato una nuova chiave di firma, DD219672, l'ho pubblicata, ho ripetuto i passaggi precedenti ma con lo stesso risultato.

Oggi, dopo aver letto e studiato più pagine man e notato che pgp-agent viene avviato automaticamente quando eseguo reprepro, ho deciso di inseguirlo per un po '.

Ho aggiunto un gpg-agent.conf con

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

E vedo nel registro che gpg-agent non trova le chiavi

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]

Finora non sono riuscito a capire dove gpg-agent sta trovando le chiavi che elenca in HAVKEY e come orientarlo nella giusta direzione per trovare la nuova chiave, DD219672, per firmare i nostri pacchetti aggiornati.

Ho avuto lo stesso problema e dopo molte frustrazioni ho finalmente rintracciato ciò che stava succedendo.

Lo repreprostrumento utilizza gpgme, che si basa su gnupg2. Una recente versione di questo ha cambiato il modo in cui viene gestito il portachiavi segreto: https://www.gnupg.org/faq/whats-new-in-2.1.html

gpg usato per mantenere le coppie di chiavi pubbliche in due file: pubring.gpge secring.gpg... Con GnuPG 2.1 questo è cambiato ... Per facilitare la migrazione al metodo no secring, gpg rileva la presenza di a secring.gpge converte le chiavi al volo al keystore di gpg-agent (questa è la private-keys-v1.ddirectory sotto la home directory di GnuPG ( ~/.gnupg)). Questo viene fatto solo una volta e un esistente secring.gpgnon viene più toccato da gpg. Ciò consente la coesistenza di versioni precedenti di GnuPG con GnuPG 2.1. Comunque, qualsiasi modifica alle chiavi private usando il nuovo gpg non apparirà quando si usano le versioni pre-2.1 di GnuPG e viceversa.

Pertanto, se crei una nuova chiave con gpg, gpg2 non la vedrà e viceversa.

Soluzione rapida che ha funzionato per me:

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

E se devi andare dall'altra parte, ovviamente:

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

A seconda della configurazione, potrebbe anche essere necessario / necessario aggiungere --export-secret-subkeys

Dopo aver fatto quanto sopra, ha repreprofunzionato correttamente con la mia nuova chiave.

Per me il problema era che ho generato le chiavi come utente ed eseguito reprepro come root .

Quello che è successo è che le chiavi che ho generato "senza sudo" vengono aggiunte al mio locale pubring.gpg. Quando eseguo sudo reprepro ...lo eseguo come root e quindi cerca di trovare la chiave in root pubring.gpge ovviamente non ne trova una.

La soluzione era eseguire tutti i gpgcomandi come root (eq. sudo -iE poi gpg --gen-key). Quando corri sudo gpg --list-keys, vedi i tasti e la linea desiderati /root/.gnupg/pubring.gpg.

Spero possa aiutare!