Reprepro export could not find signing key
We have a private debian repository that was set up years ago by an earlier system admin. Packages were signed by the older key, 7610DDDE (which I had to revoke), as shown here for the root user on the repo server.
# gpg --list-keys
/root/.gnupg/pubring.gpg
------------------------
pub 1024D/2D230C5F 2006-01-03 [expired: 2007-02-07]
uid Debian Archive Automatic Signing Key (2006) <[email protected]>
pub 1024D/7610DDDE 2006-03-03 [revoked: 2016-03-31]
uid Archive Maintainer <[email protected]>
pub 4096R/DD219672 2016-04-18
uid Archive Maintainer <[email protected]>
All commands below are as the root user. I modified the repository/conf/distributions file to use the new sub key I created explicityly for signing:
Architectures: i386 amd64 source
Codename: unstable
Components: main
...
SignWith: DD219672
But when I use dput to update a package I get
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)
And when I run reprepro export directly I get:
# 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'!
I Googled and found a couple of old threads that indicated a possible problem with reprepro finding the proper gnupg directory...so I tried this with the same results above:
# GNUPGHOME=/root/.gnupg reprepro -V export unstable
One thread suggested testing the key by signing a dummy file which seemed to work fine...at least it reported no errors and I ended up with a 576 byte bla.gpg file after it was finished.
# touch bla
# gpg -u DD219672 --sign bla
The reprepro man page also suggests "If there are problems with signing, you can try gpg --list-secret-keys value to see how gpg could interprete the value. If that command does not list any keys or multiple ones, try to find some other value (like the keyid), that gpg can more easily associate with a unique key." So I checked that as well and got:
# gpg --list-secret-keys DD219672
sec 4096R/DD219672 2016-04-18
uid Archive Maintainer <[email protected]>
And finally I was able to get in touch with the sys admin that first set up our repros and he suggested trying a key without a passphrase. So I generated a new signing key, DD219672, published it, went through the above steps again but with the same result.
Today, after more reading and studying man pages and noting that pgp-agent is automatically started when I run reprepro, I decided to chase that for a while.
I added a gpg-agent.conf with
debug-level 7
log-file /root/gpg.agent.log
debug-all
And I can see in the log that gpg-agent is not finding the keys
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]
I have so far been unable to figure out where gpg-agent is finding the keys it lists in HAVKEY and how to point it in the right direction to find the new key, DD219672, to sign our updated packages.
Solution 1:
I had the same problem, and after much frustration finally tracked down what was going on.
The reprepro tool uses gpgme, which is based on gnupg2. A recent release of that changed how the secret key ring is handled: https://www.gnupg.org/faq/whats-new-in-2.1.html
gpg used to keep the public key pairs in two files:
pubring.gpgandsecring.gpg... With GnuPG 2.1 this changed ... To ease the migration to the no-secring method, gpg detects the presence of asecring.gpgand converts the keys on-the-fly to the the key store of gpg-agent (this is theprivate-keys-v1.ddirectory below the GnuPG home directory (~/.gnupg)). This is done only once and an existingsecring.gpgis 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.
Thus, if you create a new key with gpg, gpg2 won't see it, and vice versa.
Quick fix that worked for me:
gpg --export-secret-keys | gpg2 --import -
And if you need to go the other way, of course:
gpg2 --export-secret-keys | gpg --import -
Depending on your setup, you may also want/need to add --export-secret-subkeys
After doing the above, reprepro worked properly with my new key.
Solution 2:
For me the issue was that I generated keys as user and ran reprepro as root.
What happened was that keys that I generate "without sudo" are added to my local pubring.gpg. When I run sudo reprepro ... I run it as root and therefore it tries to find the key in root's pubring.gpg and obviously does not find one.
The solution was to run all gpg commands as root (eq. sudo -i and then gpg --gen-key). Make sure when you run sudo gpg --list-keys you see your desired keys and the line /root/.gnupg/pubring.gpg.
Hope that helps!