How did I get here?

We were in the process simplifying our package creation and signing pipeline, and as such we moved the signing process for the Ubuntu packages from a dedicated Ubuntu box back to the Jenkins server itself (which had the repositories mounted over NFS). This was possible because the repository-signing utility, reprepro, is also published in EPEL.

It works! Or not…

So the GPG keys were in place, the passphrases were stored appropriately, and the calls to reprepro were made from Jenkins. It worked! No errors, and all the files were there: InRelase, Release, Release.gpg and the like. When we went to test the repository, however, we got some interesting errors from the apt-get run:

W: GPG error: http://rdev-repo.cmpny.net/Ubuntu/emerge/cmpny/bionic cmpny InRelease: The following signatures were invalid: 347D7D44139452B2214B771EC0C819FFFFFB3557
E: The repository 'http://rdev-repo.cmpny.net/Ubuntu/emerge/cmpny/bionic cmpny InRelease' is not signed.

Hmm…that’s odd. It’s using the right key; what about the signature is invalid? The gpg.conf file from the old repository creation machine matched that on the new one. The private key was the same. What’s going on?

Digging around through the old repository and newly generated one showed this discrepancy:

Old repository:

$ head -n2 18/dists/cmpny/InRelease
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

on our new repository:

$ head -n2 18/dists/cmpny/InRelease
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aha! So that’s why it’s complaining about an invalid signature: it doesn’t like the SHA1 hash. OK, fair enough, but why is it creating files with SHA1? The gpg.conf on both machines are identical. Ah well.

And a solution

Turned out to be a very simple fix. This line was added to ~/.gnupg/gpg.conf:

personal-digest-preferences SHA256

and that created an InRelease file with the proper hash for signing.