gpgverify is failing on downloads for 1.5.0/1

[bhepple]

Hi - I'm trying to package 1.5.1 for fedora, but I'm running into a gpg failure. The 1.4.0 tarballs work fine with gpgverify:

$ /usr/lib/rpm/redhat/gpgverify --keyring=6A6B35DBE9442683.gpg --signature=swappy-1.4.0.tar.gz.sig --data=swappy-1.4.0.
tar.gz
gpgv: Signature made Tue 07 Sep 2021 00:45:24 AEST
gpgv:                using RSA key F44D05A50F6C9EB5C81BCF966A6B35DBE9442683
gpgv: Good signature from "Jeremy Attali <contact@jtheoof.me>"

But the 1.5.0 and 1.5.1 tarballs fail:

$ /usr/lib/rpm/redhat/gpgverify --keyring=6A6B35DBE9442683.gpg --signature=swappy-1.5.0.tar.gz.sig --data=swappy-1.5.0.
tar.gz
gpgv: Signature made Mon 21 Nov 2022 07:38:25 AEST
gpgv:                using RSA key F44D05A50F6C9EB5C81BCF966A6B35DBE9442683
gpgv: BAD signature from "Jeremy Attali <contact@jtheoof.me>"
gpgverify: Signature verification failed.

Has the signing key changed? I tried getting a new key with:

gpg2 --recv-keys 0x6A6B35DBE9442683
gpg2 --export --export-options export-minimal 0x6A6B35DBE9442683 > 6A6B35DBE9442683.gpg

but that one fails as well.

NB the RPM-specific gpgverify script is equivalent to:

$ gpg2 --homedir=/tmp/tmp.oEXUQUlgdR --yes --output=/tmp/tmp.oEXUQUlgdR/keyring.gpg --dearmor F44D05A50F6C9EB5C81BCF966
A6B35DBE9442683.gpg
$ gpgv2 --homedir=/tmp/tmp.oEXUQUlgdR --keyring=/tmp/tmp.oEXUQUlgdR/keyring.gpg swappy-1.5.1.tar.gz.sig swappy-1.5.1.ta
r.gz
gpgv: Signature made Mon 21 Nov 2022 07:50:13 AEST
gpgv:                using RSA key F44D05A50F6C9EB5C81BCF966A6B35DBE9442683
gpgv: BAD signature from "Jeremy Attali <contact@jtheoof.me>"

[jtheoof]

Hi Bob,

I had a discussion recently with @maximbaz from the Arch team on this topic. The problem you are having is because you are using the .tar.gz provided by github in the release. The problem is that github has probably not upgraded to git >= 2.38.0 (see this thread on Arch) So this forced me to sign and upload the .tar.gz myself. You can see it in the release, next to the .sig file. See here. Because of that, I had to update my release script to reflect those changes.

If I do that and follow your steps I get:

» gpgv2 --homedir=/tmp/tmp.oEXUQUlgdR --keyring=/tmp/tmp.oEXUQUlgdR/keyring.gpg swappy-1.5.1.tar.gz.sig swappy-1.5.1.tar.gz
gpgv: Signature made Sun 20 Nov 2022 04:50:13 PM EST
gpgv:                using RSA key F44D05A50F6C9EB5C81BCF966A6B35DBE9442683
gpgv: Good signature from "Jeremy Attali <contact@jtheoof.me>"

However this whole process is rather pointless. The tag, which I base myself on for the release is properly signed.

Not trusting this, implies not trusting github. Maxim was telling me that Arch supports signed git tags. I'm hoping Fedora does too.

I'm thinking of dropping this cumbersome process (i.e: signing and pushing the .sig and .tar.gz) for the next release. Simply sign the tag and create a release out of it. Can you please do a bit of research on your side to see if that's possible?

Also, for your consideration, git now supports ssh-based signatures. I won't stop using PGP because I think distros don't support this very well but just so you know.

[bhepple]

Yep - that did the trick!! Thanks a lot, it's on it's way to general release.

I've posted the question about the "signed git tags" on the devel list - there live the deep-thinking ones.

[bhepple]

So I got a prolific and intelligent response for the Redhat gurus which I will attempt to reproduce the gist here. If you want the full discussion, the best thing would be to join the devel@lists.fedoraproject.org list ...

"... Arch supports signed git tags. I'm hoping Fedora does too.

The answer, basically is 'no': from one respondent:

On Fedora you must upload source tarball, its signature and public key
to the Fedora look-aside cache, because builders have no network access
for security reasons.

From another:

During the early days of packaging, there were a set of packages which would pull things from the internet to 'complete' the build. This led to non-repeatable builds, and in some cases security problems when a precompiled blob on sunsite.unc.edu was compromised. There were also some sets of code which tried to 'exfiltrate' things during a build. Cutting off internet access helped cut off these vectors of problems for the OS and allowed interested parties to rebuild the OS from 'scratch' as needed. It made things harder overall, but at the time was better than the alternative of having a rebuild be drastically different from the first or 'other code' added into the system without knowing why.

tl;dr: There is always a percentage of jerks out there who like to make life miserable for everyone else. Removing the internet helps lower their free ride.

and then:

Arch Linux has internet access in their builders. Their PKGBUILD files
can fetch content from the internet as part of their build process.
That's why they can do that. Neither Fedora, nor Debian, nor Ubuntu,
nor openSUSE would allow that.

[jtheoof]

Thanks for the investigation. I'll keep pushing the signed file along with the tar.gz.