On 11/04/2016 12:29 PM, Andreas Heigl wrote:
It's a feature from git itself, not github. https://git-scm.com/book/uz/v2/Git-Tools-Signing-Your-Work
It is based on GPG-Keys so there's no central trusted instance which can be a benefit or a curse depending on how you look at it.
Except for 2016f (where I used a "wrong" key), I have been signing these tags using the public key ED97E90E62AA7E34 registered at pgp.mit.edu. I didn't know until today about GitHub's "Verified" UI that was introduced in April. To help out with that, I just now uploaded the public key to my GitHub account, so that GitHub now verifies release tags at <https://github.com/eggert/tz/tags>. You can also verify the tags using plain Git, assuming you have imported the public key from pgp.mit.edu: $ git tag -v 2016i object 9774c293b7ea6ec7be851cb0b2a0807840e6793e type commit tag 2016i tagger Paul Eggert <eggert@cs.ucla.edu> 1478067592 -0700 Release 2016i gpg: Signature made Tue 01 Nov 2016 11:21:17 PM PDT using RSA key ID 62AA7E34 gpg: Good signature from "Paul Eggert <eggert@cs.ucla.edu>" Hmm, I now see that the signature timetamp is later than the release timestamp (1478067592 = 2016-11-01 23:19:52 -0700, the time stamp documented in the NEWS file). That is annoying. I wonder if this discrepancy can be fixed in later releases?