When managing a Debian repository with reprepro, one of the most frustrating errors occurs when the system can't locate your signing key. The typical error message looks like this:

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

First, let's confirm the key actually exists in your keyring:

# gpg --list-secret-keys DD219672
sec   4096R/DD219672 2016-04-18
uid                  Archive Maintainer 

If this returns your key (as it should), we need to understand why reprepro can't see it.

The gpg-agent plays a crucial role here. Enable debug logging to see what's happening:

# Create gpg-agent config
echo "debug-level 7
log-file /root/gpg.agent.log
debug-all" > /root/.gnupg/gpg-agent.conf

# Restart agent
gpgconf --kill gpg-agent

In the debug logs, you'll often see entries like:

2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 <- HAVEKEY C2C5C59E5E90830F314ABB66997CCFAACC5DEA2F
2016-04-18 15:54:00 gpg-agent[15582] DBG: chan_5 -> ERR 67108881 No secret key 

This indicates the agent can't access your secret keys. Try these solutions:

Modify your distributions file to use the full fingerprint:

SignWith: 0xDD219672

Or use the email identifier:

SignWith: root@xxxxxxxxxx.com

Sometimes reprepro needs explicit GPG home directory specification:

# Export the variable first
export GNUPGHOME=/root/.gnupg

# Then run reprepro
reprepro -V export unstable

Verify the key works outside reprepro:

# Create test file
echo "test" > testfile.txt

# Sign with the key
gpg -u DD219672 --sign testfile.txt

# Verify signature
gpg --verify testfile.txt.gpg

Sometimes the key needs its trust level updated:

# Start GPG interactive shell
gpg --edit-key DD219672

# In the interactive shell:
gpg> trust
Your decision? 5
gpg> save

If you're running reprepro under a different user (like www-data for web access):

# Import key to target user
sudo -u www-data gpg --import /root/.gnupg/private.key

# Or copy the entire keyring
sudo cp -r /root/.gnupg /home/www-data/
sudo chown -R www-data:www-data /home/www-data/.gnupg

After applying fixes, test repository operations:

# Clear any cached state
reprepro clearvanished

# Force export
reprepro -V export unstable

# Check Release file signature
gpg --verify /path/to/repo/dists/unstable/Release.gpg

---

When maintaining private Debian repositories, one particularly frustrating issue arises when reprepro fails to locate signing keys despite proper configuration. The error message Could not find any key matching 'KEYID'! often appears even when GPG can clearly list the key. Here's how we can systematically address this.

First, let's verify the key availability in different contexts:

# Check public keys
gpg --list-keys

# Verify secret key availability
gpg --list-secret-keys DD219672

# Test signing capability
touch testfile
gpg -u DD219672 --sign testfile

Reprepro interacts with GPG differently than direct command-line usage. The key points where things might break:

• GPG agent communication
• Keyring access permissions
• Passphrase handling
• Key ID formatting

Here are concrete steps that have resolved similar issues in production environments:

# Solution 1: Force specific GPG home directory
GNUPGHOME=/root/.gnupg reprepro -v export unstable

# Solution 2: Use full key fingerprint instead of short ID
# In distributions file:
SignWith: 0x1234567890ABCDEF1234567890ABCDEF12345678

# Solution 3: Disable GPG agent temporarily
gpgconf --kill gpg-agent
GPG_AGENT_INFO= reprepro export unstable

When the agent is the culprit, detailed logging helps:

# Create debug configuration
echo "debug-level 7
log-file /var/log/gpg-agent.log
debug-all" > ~/.gnupg/gpg-agent.conf

# Restart agent and reproduce issue
gpgconf --kill gpg-agent
reprepro export unstable

# Examine logs for HAVEKEY entries
tail -f /var/log/gpg-agent.log

The way you reference keys matters significantly. Try these variations in your distributions file:

# By key ID
SignWith: DD219672

# By fingerprint
SignWith: 0xABCD1234...

# By email
SignWith: root@example.com

# By keygrip (from gpg --with-keygrip --list-secret-keys)

Sometimes the issue lies in reprepro's configuration inheritance. Ensure these files are properly set up:

• conf/distributions - Main signing configuration
• conf/options - Global repository settings
• conf/incoming - For upload processing

Example options file addition:

ask-passphrase
gnupghome /root/.gnupg