Debian Stretch Reprepro 'The following signatures were invalid'
I’ve been using reprepro for a while now to run a Debian APT repo. Which worked fine but on Stretch it has been throwing errors left and right.
If you add an existing distro upstream you’ll get something like the following:
W: GPG error: https://somehost.tld distro InRelease: The following signatures were invalid: HASH
W: The repository 'https://somehost.tld distro InRelease' is not signed.
N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
N: See apt-secure(8) manpage for repository creation and user configuration details.
This is due to Stretch no longer allowing SHA1 signing because it’s insecure or whatever.
However, nothing seems to properly show what to do to fix this, so here goes:
GnuPG configuration
Important things to do, first off we got to tell GnuPG to no longer prefer SHA1 at all.
Open up ~/.gnupg/gpg.conf
# Prioritize stronger algorithms for new keys.
default-preference-list SHA512 SHA384 SHA256 BZIP2 ZLIB ZIP Uncompressed
# Use a stronger digest than the default SHA1 for certifications.
cert-digest-algo SHA512
# these are critical, without it it'll keep using SHA1 for whatever reason
personal-digest-preferences SHA512
personal-cipher-preferences SHA512
# Optional, but recommended
default-key YOUR-NEW-KEY-HASH
If your key was 2048 bits at least, you’re now good to go. In my case it was simply a matter of removing the new Stretch distro dir (since I had no packages in it anyway) and having reprepro generate it on includedeb.
After that moment it was working for me.
Journey goes on…
Secondly, if your original key wasn’t atleast 2048bit yet you’ll have to either create a new key or update the existing one.
New Key
To create a new one, quite easy just do gpg --gen-key and follow the steps. With the new config in place you’ll be good to go.
Afterwards just do gpg --list-keys and take the new sub-key hash and configure reprepro to use it (/reprepro/dir/conf/distributions) and mark that for the following:
SignWith: YOUR-NEW-KEY-HASH
You can also add it to ~/.gnupg/gpg.conf
default-key YOUR-NEW-KEY-HASH
Update the Key
Now if you want to use an existing key so you don’t have to replace it everywhere (it’ll keep working for pre-Stretch, so this is good) we have to do a bit more steps.
To remove the SHA1 digest from the key these steps are needed, we’ll need to use gpg --edit-key KEYHASH.
Now this command is very arcane and now very clear so here are some notes of what I found.
When I do gpg --edit-key ABCDEFG I get an interactive prompt:
gpg> showpref
[ultimate] (1). terwey <foo@bar.com>
Cipher: AES256, AES192, AES, CAST5, 3DES
Digest: SHA512, SHA384, SHA256, SHA224, SHA1
Compression: BZIP2, ZLIB, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
But removing something isn’t so easy, it has to be in the format this system understands
gpg> pref
[ultimate] (1). terwey <foo@bar.com>
S9 S8 S7 S3 H10 H9 H8 H11 Z3 Z2 Z1 Z0 [mdc] [no-ks-modify]
Ehr, yeah ok, great what does this mean? It’s the same info as before just the internal values, he’s a little table. Everything prefixed with an S is a Cipher, H is the Digest and Z is the compression.
This table is based on me playing a bit with the options it can set and what it returned, it’s not gospel.
| GNUPG Code | Meaning |
|---|---|
| S13 | CAMELLIA256 |
| S12 | CAMELLIA192 |
| S11 | CAMELLIA128 |
| S10 | TWOFISH |
| S9 | AES256 |
| S8 | AES192 |
| S7 | AES |
| S4 | BLOWFISH |
| S3 | CAST5 |
| H11 | SHA224 |
| H10 | SHA512 |
| H9 | SHA384 |
| H8 | SHA256 |
| H3 | RIPEMD160 |
| H2 | SHA1 |
| H1 | MD5 |
| Z3 | BZIP2 |
| Z2 | ZLIB |
| Z1 | ZIP |
| Z0 | Uncompressed |
So it seems what I want is the following:
gpg> setpref S9 S8 H10 H8 Z3 Z2 Z1 Z0
Set preference list to:
Cipher: AES256, AES192, 3DES
Digest: SHA512, SHA256, SHA1
Compression: BZIP2, ZLIB, ZIP, Uncompressed
Features: MDC, Keyserver no-modify
That’s weird, SHA1 is still there… digging a little deeper in RFC 4880 - OpenPGP Message Format
Since SHA1 is the MUST-implement hash algorithm, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly.
So yeah, guess for my key it doesn’t really matter. However it could be in your key it’s at the front and then it’s the preferred digest to use. In that case, save the key with the new preference and resign the repo.