L'exportation Reprepro n'a pas pu trouver la clé de signature

Nous avons un dépôt Debian privé qui a été mis en place il y a des années par un ancien administrateur système. Les packages ont été signés par l'ancienne clé, 7610DDDE (que j'ai dû révoquer), comme indiqué ici pour l'utilisateur root sur le serveur 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>

Toutes les commandes ci-dessous sont en tant qu'utilisateur root. J'ai modifié le fichier repository / conf / distributions pour utiliser la nouvelle sous-clé que j'ai créée explicitement pour la signature:

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

Mais quand j'utilise dput pour mettre à jour un paquet, j'obtiens

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)

Et lorsque j'exécute l'export reprepro directement, j'obtiens:

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

J'ai googlé et trouvé quelques anciens threads qui indiquaient un problème possible avec reprepro pour trouver le bon répertoire gnupg ... alors j'ai essayé cela avec les mêmes résultats ci-dessus:

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

Un thread a suggéré de tester la clé en signant un fichier factice qui semblait bien fonctionner ... au moins, il n'a signalé aucune erreur et je me suis retrouvé avec un fichier bla.gpg de 576 octets une fois terminé.

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

La page de manuel reprepro suggère également "S'il y a des problèmes de signature, vous pouvez essayer la valeur gpg --list-secret-keys pour voir comment gpg pourrait interpréter la valeur. Si cette commande ne répertorie aucune clé ou plusieurs clés, essayez de trouver une autre valeur (comme le keyid), que gpg peut plus facilement associer à une clé unique. " J'ai donc vérifié cela aussi et j'ai obtenu:

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

Et finalement, j'ai pu entrer en contact avec l'administrateur système qui a d'abord configuré nos repros et il a suggéré d'essayer une clé sans mot de passe. J'ai donc généré une nouvelle clé de signature, DD219672, je l'ai publiée, j'ai recommencé les étapes ci-dessus mais avec le même résultat.

Aujourd'hui, après plus de lecture et d'étude des pages de manuel et avoir remarqué que pgp-agent démarre automatiquement lorsque j'exécute reprepro, j'ai décidé de poursuivre cela pendant un certain temps.

J'ai ajouté un gpg-agent.conf avec

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

Et je peux voir dans le journal que gpg-agent ne trouve pas les clés

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]

Jusqu'à présent, je n'ai pas pu déterminer où gpg-agent trouve les clés qu'il répertorie dans HAVKEY et comment le diriger dans la bonne direction pour trouver la nouvelle clé, DD219672, pour signer nos packages mis à jour.

J'ai eu le même problème, et après beaucoup de frustration, j'ai finalement retrouvé ce qui se passait.

L' repreprooutil utilise gpgme, qui est basé sur gnupg2. Une version récente de cela a changé la façon dont le porte-clés secret est géré: https://www.gnupg.org/faq/whats-new-in-2.1.html

gpg utilisé pour conserver les paires de clés publiques dans deux fichiers: pubring.gpget secring.gpg... Avec GnuPG 2.1, cela a changé ... Pour faciliter la migration vers la méthode sans secret, gpg détecte la présence de a secring.gpget convertit les clés à la volée dans le magasin de clés de gpg-agent (c'est le private-keys-v1.drépertoire sous le répertoire de base de GnuPG ( ~/.gnupg)). Ceci n'est fait qu'une seule fois et un existant secring.gpgn'est alors plus touché par gpg. Cela permet la coexistence d'anciennes versions de GnuPG avec GnuPG 2.1. Cependant, toute modification des clés privées utilisant le nouveau gpg n'apparaîtra pas lors de l'utilisation des versions pré-2.1 de GnuPG et vice versa.

Ainsi, si vous créez une nouvelle clé avec gpg, gpg2 ne la verra pas, et vice versa.

Solution rapide qui a fonctionné pour moi:

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

Et si vous devez aller dans l'autre sens, bien sûr:

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

En fonction de votre configuration, vous pouvez également vouloir / devoir ajouter --export-secret-subkeys

Après avoir fait ce qui précède, repreprotravaillé correctement avec ma nouvelle clé.

Pour moi, le problème est que j'ai généré des clés en tant qu'utilisateur et exécuté reprepro en tant que root .

Ce qui s'est passé, c'est que les clés que je génère "sans sudo" sont ajoutées à ma section locale pubring.gpg. Lorsque je lance, sudo reprepro ...je l'exécute en tant que root et par conséquent, il essaie de trouver la clé dans root pubring.gpget, évidemment, n'en trouve pas.

La solution consistait à exécuter toutes les gpgcommandes en tant que root (par exemple sudo -i, puis gpg --gen-key). Assurez-vous que lorsque vous exécutez, sudo gpg --list-keysvous voyez vos clés souhaitées et la ligne /root/.gnupg/pubring.gpg.

J'espère que cela pourra aider!