Sign releases with PGP key

[maximbaz]

Hey!

I've seen you sign one of the recent commits using your PGP key, that means you must be using PGP 😛

What do you think about signing releases? Instead of providing hashsums (or in addition, if you want).

PGP signatures will not only help ensuring that downloaded archive is not corrupted, but will also verify authenticity and in general reduce attack vector when your app is being built by other people and distributed via distro packages.

For packaging we'd need a signature for sources tarball (.tar.gz) that Github automatically provides for you on every release, signatures for other attachments would be appreciated as well 🙂

Here's what I would suggest to do:

1. For transparency, put in README your key ID, something like below would be enough (it's my key in the example below):

Releases are signed with the following PGP key: `8053EB88879A68CB4873D32B011FDC52DA839335`

2. Publish your key to http://keys.gnupg.net/

3. The sources tarball is reproducible and can be recreated using the following git command:

git archive -o xplr-<version>.tar.gz --format tar.gz --prefix "xplr-<version>/" "<tag>"

So for example, to get a signature you'd run this (mind where v before version is used and where is not):

git archive -o xplr-0.7.2.tar.gz --format tar.gz --prefix "xplr-0.7.2/" "v0.7.2"
gpg --detach-sign xplr-0.7.2.tar.gz
rm xplr-0.7.2.tar.gz

Let me know if you need any help! 🙂

[sayanarijit]

Thanks for the suggestions and detailed explanation. But I haven't seen many repos publishing packages with pgp. Are there any downsides? Will non pgp/git users be able to download xplr without having to setup key or installing git?
Also, the tarballs are published automatically by gh actions when I publish a release. It might be difficult to sign them in the runners.

[maximbaz]

No downsides, except some extra work for you to set this up 😁

Verifying signature is completely optional for users, just like it's optional to verify sha* hashsum file that you are attaching to the releases now.

You can think of it like this, hashsums help to ensure integrity (file wasn't corrupted during download), signatures help ensure authenticity (there was no MITM attacker who made me download evil file with evil hashsum - they can forge hashsum, but not the signature) while also indirectly help ensure integrity (signature will not match a corrupted file). But you can also just download the file and hope that it wasn't corrupted or modified along the way 😄

Also, the tarballs are published automatically by gh actions when I publish a release. It might be difficult to sign them in the runners.

Aah hmm 🤔 Yeah depending on your preference, I can see two alternatives:

• Either you sign locally with your own PGP key, we can make a Makefile which wraps all the necessary commands above plus uses gh to upload the extra signature back to the latest release.
• Or create a new PGP key specifically for xplr, and let Github runners use it (so put it in repo secrets).

nnn went the former way, so this means you'd push a git tag to trigger Github actions to start the release, and then you'd run make upload-sign which will create and upload the signature to the release. Notice that nnn only signs the tarball, not other release artifacts, it may be because of simplicity (it's easy to recreate the sources tarball using git command, but to sign other files you'd have to download them from github, after github actions finished the build and uploaded them to release).

But I know some projects who went the latter way. It's a bit less nice because now Github has access to your private key, but I guess with proper care the risk is limited and this is better than nothing 🙂

Let me know what you think. I can help with whatever way you choose to go. It's also okay if you don't want to deal with any of this 🙂

orhun and I now maintain xplr package in Arch community repo (I see he already shared the news 🙂), so rest assured if you choose to generate the signatures, it will be put to good use for the Arch package! 🙂

[sayanarijit]

Sounds fun 👍 . I'll try this in the coming weekend.

[sayanarijit]

@maximbaz does this work with the master branch?

I had to tar gzip the signature because of github upload limitations.

xplr.tar.gz.sig.tar.gz

http://keys.gnupg.net/pks/lookup?op=get&search=0x0F8EF5258DC38077

[maximbaz]

Can you show me what kind of limitation you have? I use it in other projects, should work fine. I'm afraid archived signature might not play well with packaging automation....

Try also gpg --detach-sign --armor, it will create .asc file instead of .sig, does that work better?

---

If you are testing by hand, generate please a signature for the latest release, I'll be verifying by:

• downloading "sources tarball" from the latest github release, that github itself generated
• downloading your signature file
• running gpg --verify

[sayanarijit]

I meant limitation of uploading the sig in this comment.

xplr.tar.gz.asc.txt

This is only to verify with you if this works (i.e. you're able to verify the signature). Then I'll start setting up GH actions.

[maximbaz]

interestingly it seems like the signature was made using a different key ID 🤔

$ gpg --verify xplr.tar.gz.asc.txt xplr-0.13.1.tar.gz
gpg: Signature made 2021-06-03T12:08:39 CEST
gpg:                using RSA key 3C731FB9D54A7FF49D7497F17D7BF809E7378863
gpg: requesting key 0x7D7BF809E7378863 from hkp server keys.gnupg.net
gpg: Can't check signature: No public key

[sayanarijit]

Ah ok... so that's how it works. It's actually my previous signature.

Try verifying xplr.tar.gz

[sayanarijit]

Good to know GitHub automatically signs the releases.

[maximbaz]

You might have accidentally attached an archive, and not a new signature :) Signature file contains which key was used to sign an archive.

Or if you want to use a different key, just make sure to publish it to keys.gnupg.net

When you sign, you can specify which key to use, using gpg --detach-sign --armor --default-key KEYID xplr.tar.gz, or have that in your ~/.gnupg/gpg.conf (like this)

[maximbaz]

Maybe just to give you another reference, an example how I do it in another project:

https://github.com/maximbaz/yubikey-touch-detector/blob/2b9cd230493ef0c9f924d165614289c49384f562/Makefile#L50-L54

https://github.com/maximbaz/yubikey-touch-detector/releases/tag/1.9.1

[sayanarijit]

The signature is the same. I'm sure git is using this signature to sign the archive I sent.

[maximbaz]

Aaah I think we misunderstood each other 😁 The problem with that signature is that the key that you used to sign is not published on keys.gnupg.net:

$ gpg --verify xplr.tar.gz.asc.txt xplr-0.13.1.tar.gz
gpg: Signature made 2021-06-03T12:08:39 CEST
gpg:                using RSA key 3C731FB9D54A7FF49D7497F17D7BF809E7378863
gpg: requesting key 0x7D7BF809E7378863 from hkp server keys.gnupg.net  <------
gpg: Can't check signature: No public key

[sayanarijit]

The archieve I just sent is signed using a published signature. Hence, you should be able to verify it.

[maximbaz]

If you made a new signature, I need to download it again :) The archive itself does not contain info, the signature file that you attached earlier was made using key 3C731FB9D54A7FF49D7497F17D7BF809E7378863 and not using http://keys.gnupg.net/pks/lookup?op=get&search=0x0F8EF5258DC38077

Could you please just from scratch attach new signature and new archive? :)

[sayanarijit]

xplr-v0.13.1.tar.gz

xplr-v0.13.1.tar.gz.asc.txt

[sayanarijit]

Does it work now? :D

[sayanarijit]

➜  xplr git:(main) ✗ gpg --verify xplr-v0.13.1.tar.gz.asc.txt xplr-v0.13.1.tar.gz
gpg: Signature made Thu 03 Jun 2021 04:52:54 PM IST
gpg:                using RSA key D59CA14710C17C6B24717AF90F8EF5258DC38077
gpg: Good signature from "Arijit Basu (June 3, 2021) <sayanarijit@gmail.com>" [ultimate]

Shows the current signature now.

[maximbaz]

Great success 🎉

[sayanarijit]

FInally, success with https://github.com/sayanarijit/xplr/releases/tag/v0.13.5

[maximbaz]

Works like a charm, thank you 🙂