
Creating signed GitHub releases - ashitlerferad
https://wiki.debian.org/Creating%20signed%20GitHub%20releases
======
creshal
Or, alternatively:

1\. Tag your release with `git tag -s`

2\. `git push --follow-tags` (or `git push remotename tagname` in git <1.8.3)

3\. Upload your pubkey to github.

Much less effort…

~~~
dsp1234
Do the above steps generate an actual signed release, or just a signed tag?

~~~
creshal
A tag, not a release. I didn't realize there was a difference, but in
hindsight, I'd argue it's superior anyway: I'm _much_ more comfortable to sign
my local repository copy than signing an archive generated by github in a non-
reproducible way.

I can verify the contents of github's archives, but I cannot, in good faith,
say I've verified that the archives do not contain malicious code that
triggers vulnerabilities in zip/tar/gzip.

~~~
chungy
Reproducing GitHub's archives locally is trivial. They just use a standard git
command to do it anyway.

git archive -o project-0.5.tar.gz --prefix project-0.5/ v0.5

~~~
creshal
I think we have different standards for "reproducible". You can replicate the
archive structure and naming, but the archive metadata – and thus checksums –
will be different:

$ curl -sL
[https://github.com/creshal/yspave/archive/0.1.0.zip](https://github.com/creshal/yspave/archive/0.1.0.zip)
| sha512sum

375564f127b46f3d1208c30b4eb5c39725985ca09d7bacf940d346727e8bcf9362966f8523c39e6c4f6f1a86b52ceba8823c2f4b016fdedb5947cd6a6bafc930
-

$ git clone git@github.com:creshal/yspave.git

…

$ cd yspave

$ git archive -o 0.1.0.zip --prefix yspave-0.1.0/ 0.1.0

$ sha512sum 0.1.0.zip

aca1163d5270e8ad6796f10511f49b0cf5fe61007fed0786a6643ae522e59a6aa7d6b0cddf4e5b94a435da8d99aa09b2f2ebef7788a82d4c2e7d8d4ad79e0634
0.1.0.zip

–––––

So, I can verify that the contents weren't tampered with, but I cannot verify
the archives themselves unless I happen to understand the zip/tar/gz…
specifications better than most people implementing it.

~~~
chungy
That's interesting. I'm not able to replicate your results. Cloning that
respository and doing the same git archive command produces an identical file
to what GitHub serves.

I'm on a fully updated Arch Linux with the latest Git. If you have an older
version, that might be making the difference.

~~~
Xylakant
I can reproduce the result: The content of the file is identical, the checksum
differs.

------
rickycook
They missed the bit about verifying the validity of the content of the
tarball... Given that you're essentially guarding against GitHub going rogue,
that's half the point right?

~~~
creshal
Verifying the content is one thing, what about making sure the archive itself
isn't malicious and triggering tar/gzip/zip vulnerabilities? In my experience,
github's archives are not generated in a reproducible way.

~~~
ashitlerferad
github archives are definitely generated in a reproducible way.

~~~
LukeShu
They are now. They weren't 2 or 3 years ago.

------
embik
> 4\. Go back to your "Releases" section and download the tarball
> mysoftware-0.4.tar.gz automatically generated by GitHub.

If only. That's by far my biggest irk with GitHub releases because they only
use the tag as name for the tarball (e.g. v0.4.tar.gz). Building RPM packages
with those tarballs is a bit of a pain because RPM building tools expect all
tarballs in one directory and you don't know which tarball belongs to which
software. Maybe I'm just being ignorant here.

~~~
creshal
It's not github's fault that RPM's tooling is stuck in the 90s, to be honest.
makepkg and others support renaming tarballs during download to cover this use
case.

~~~
embik
I don't disagree, but it just feels off to tell a packaging tool to rename a
tarball because the default name is not verbose enough to even identify the
tarball.

~~~
justincormack
But even so it is designed to be likely to get accidental collisions.

------
richardwhiuk
What's the threat model you are defending against here?

GitHub changing the binary being downloaded? They could serve a different
signature.

Another committer changing the tag? They could equally change the
signature....

~~~
edwintorok
Github doesn't have your private key, so they won't be able to serve a valid
signature. The only thing they could do is to substitute an older signed
version when you request a newer version.

~~~
ashitlerferad
They could create a new private key using your name. Most people will trust
'Verified' on a web page more than the OpenPGP web of trust.

~~~
sneak
Not sure why you're being downvoted, this "what is the threat model here" was
my first thought, too, and this comment is also correct, as well.

~~~
ashitlerferad
Probably my "Most people" quip.

------
cdnsteve
Signed releases should be required for any package management system. I'm
finding Ruby to be lacking in this area:

`bundle install --trust-policy HighSecurity`

------
dmvaldman
There appear to be a lot of shots taken behind the basket - even as far back
at the 3 pt line. Is this a mistake in measurement?

~~~
sb8244
[https://news.ycombinator.com/item?id=11495374](https://news.ycombinator.com/item?id=11495374)

