fragen stichworte

Der Reprepro-Export konnte den Signaturschlüssel nicht finden

Wir haben ein privates Debian-Repository, das vor Jahren von einem früheren Systemadministrator eingerichtet wurde. Pakete wurden mit dem älteren Schlüssel 7610DDDE (den ich widerrufen musste) signiert, wie hier für den Root-Benutzer auf dem Repo-Server gezeigt.

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

Alle folgenden Befehle gelten als Root-Benutzer. Ich habe die Repository-/conf/distributions-Datei geändert, um den neuen Unterschlüssel zu verwenden, den ich explizit zum Signieren erstellt habe:

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

Wenn ich jedoch mit dput ein Paket aktualisiere, bekomme ich

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)

Und wenn ich den reprepro-Export direkt ausführen, bekomme ich:

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

Ich habe gegoogelt und ein paar alte Threads gefunden, die auf ein mögliches Problem hinweisen, dass reprepro das richtige gnupg-Verzeichnis findet ... also habe ich dies mit den gleichen Ergebnissen oben versucht:

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

Ein Thread schlug vor, den Schlüssel zu testen, indem er eine Dummy-Datei signierte, die gut zu funktionieren schien ... Zumindest meldete er keine Fehler und am Ende erhielt ich eine 576-Byte-Datei bla.gpg.

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

Die Reprepro-Manpage schlägt außerdem Folgendes vor: "Wenn Probleme beim Signieren auftreten, können Sie gpg --list-secret-keys value versuchen, um zu sehen, wie gpg den Wert interpretieren kann. Wenn dies nicht der Fall ist Listet alle oder mehrere Schlüssel auf. Versuchen Sie, einen anderen Wert (wie die keyid) zu finden, den gpg leichter mit einem eindeutigen Schlüssel verknüpfen kann. " Also habe ich das auch überprüft und bekam:

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

Und schließlich konnte ich mich mit dem sys-Administrator in Verbindung setzen, der zuerst unsere Repros aufstellte. Er schlug vor, einen Schlüssel ohne Passphrase zu verwenden. Also erzeugte ich einen neuen Signaturschlüssel, DD219672, veröffentlichte ihn, ging die obigen Schritte erneut durch, jedoch mit dem gleichen Ergebnis.

Heute, nachdem ich mehrmals Manpages gelesen und studiert und festgestellt hatte, dass der pgp-agent beim Ausführen von reprepro automatisch gestartet wird, habe ich mich entschlossen, dies eine Zeit lang zu verfolgen.

Ich habe eine gpg-agent.conf mit

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

Und ich kann im Protokoll sehen, dass gpg-agent die Schlüssel nicht findet

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]

Bisher konnte ich nicht herausfinden, wo gpg-agent die in HAVKEY aufgelisteten Schlüssel findet und wie er in die richtige Richtung weist, um den neuen Schlüssel DD219672 zu finden, um unsere aktualisierten Pakete zu signieren.

antworten

Ich hatte das gleiche Problem, und nach langer Frustration konnte ich endlich herausfinden, was vor sich ging.

Das Tool reprepro verwendet gpgme, das auf gnupg2 basiert. Eine kürzlich veröffentlichte Version hat die Handhabung des geheimen Schlüsselringes verändert: https://www.gnupg.org/faq/whats-new-in-2.1.html

gpg used to keep the public key pairs in two files: pubring.gpg and secring.gpg ... With GnuPG 2.1 this changed ... To ease the migration to the no-secring method, gpg detects the presence of a secring.gpg and converts the keys on-the-fly to the the key store of gpg-agent (this is the private-keys-v1.d directory below the GnuPG home directory ( ~/.gnupg )). This is done only once and an existing secring.gpg is then not anymore touched by gpg. This allows co-existence of older GnuPG versions with GnuPG 2.1. However, any change to the private keys using the new gpg will not show up when using pre-2.1 versions of GnuPG and vice versa.

Wenn Sie also einen neuen Schlüssel mit gpg erstellen, wird gpg2 ihn nicht sehen und umgekehrt.

Schnelle Lösung, die für mich funktioniert hat:

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

Und wenn Sie natürlich in die andere Richtung gehen müssen:

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

Abhängig von Ihrer Konfiguration möchten/müssen Sie möglicherweise --export-secret-subkeys

hinzufügen

Nachdem Sie die obigen Schritte durchgeführt hatten, funktionierte reprepro ordnungsgemäß mit meinem neuen Schlüssel.

Für mich war das Problem, dass ich Schlüssel als Benutzer generiert und reprepro als root ausgeführt habe.

Was passiert ist, ist, dass Schlüssel, die ich "ohne sudo" erzeuge, zu meinem lokalen pubring.gpg hinzugefügt werden. Wenn ich sudo reprepro ... starte, führe ich es als root aus und versuche daher den Schlüssel in root pubring.gpg zu finden und finde offensichtlich keinen.

Die Lösung bestand darin, alle gpg -Befehle als root (eq. sudo -i und dann gpg --gen-key) auszuführen. Stellen Sie sicher, dass Sie beim Ausführen von sudo gpg --list-keys Ihre gewünschten Schlüssel und die Zeile /root/.gnupg/pubring.gpg sehen.

Hoffe das hilft!