
GPG signature verification - edward
https://github.com/blog/2144-gpg-signature-verification
======
xgbi
That competition between gitlab and github is starting to give good results: 3
weeks in a row with news from both, each time with long-awaited features.

If this doesn't show that competition is good, I don't know what else could!

~~~
sytse
For sure the competition is making us both better. Coincidentally we're
working on the same feature in [https://gitlab.com/gitlab-org/gitlab-
ce/issues/4232](https://gitlab.com/gitlab-org/gitlab-ce/issues/4232) but
congrats to GitHub for shipping it sooner.

~~~
ChristianBundy
Looks this this is Gitlab EE only though, is that right?

~~~
gpm
(I only know what I read on the issue tracker)

The part that GitHub implemented (uploading keys to the site, displaying
verified signed commits in the UI) looks like it is both.

Configuring a project to only accept signed commits in various ways looks to
be EE only.

------
JoshTriplett
The lack of something is hard to notice, especially when the majority of
people don't sign commits. Perhaps if people start widely signing commits and
tags, Github could add an option to explicitly mark commits or tags as
"unverified" if they fall after a specified date and don't have a signature.

~~~
joeyh
I decided to start signing all my commits as a matter of policy, since the
cost to break SHA1 is now estimated at $75k. There are certainly git repos
that it would be worth $75k to compromise, and a single birthday attack
collision in SHA1 can be reused to compromise multiple git repositories
(requires some social engineering). So I think that is a good policy now.

Github could have a setting like "flag unsigned commits from me after $date"
that allows this kind of policy to be communicated.

~~~
epistasis
Note that signed commits only validate the commit file contents up to the SHA1
of the top level tree, it's not a GPG signature of the entire tree state.

This means that a SHA1 collision on the tree object, or any blob object, still
results in a valid GPG signature.

So git GPG doesn't provide any additional security over SHA1; it only provides
proof that a certain person signed a SHA1 and the commit message.

~~~
gpm
I was curious so I ran git in a debugger and found the buffer it is actually
signing, it looks like this in case anyone else is wondering:

"tree 33191145e9a307b7ca5c6e4aa6e74a4904426cba\nparent
a2c6664cf085720cba3f92e4a7348c46369a869e\nauthor Greg Morenz
<morenzg@gmail.com> 1459911016 -0400\ncommitter Greg Morenz
<morenzg@gmail.com> 1459911016 -0400\n\nthe commit message\n"

------
the_mitsuhiko
I'm a huge fan of the concept, but unfortunately gpg is such a terrible
program that I completely gave up using signed commits from basic testing. The
agent that does exist I could not convince of working either at all or with
git and entering a long passphrase on every commit is not my thing.

Are there any efforts in writing a minimal version of it with a modern and
flexible UI?

~~~
lolidaisuki
> but unfortunately gpg is such a terrible program

I can't understand what people find to be so bad in it. It took half an hour
to learn the basic usage and the commands aren't hard to remember at all.

Can you please elaborate?

~~~
DasIch
Essentially you want 3 operations. Generate keypair, encrypt X with key,
decrypt X with key.

You want this as a library that's impossible to misuse and a nice CLI on top.

The fact that it took you half an hour to understand the "basic usage" is
ridiculous. The GPG developers have failed in the worst possible way when it
comes to the design of their software. It's so bad I find it incomprehensible
how that could have happened on accident.

If they would be working on something non-cryptographic, that would be one
thing but for a cryptographic tool that's unacceptable. The design and ease of
use is just as important as the cryptographic algorithms themselves for such a
tool because any friction causes people to avoid cryptography.

~~~
ashitlerferad
What about signing and verification?

~~~
DasIch
Right, forgot about those. Still those are just two more commands, which
brings us to 5. That shouldn't push the complexity up significantly and
doesn't change anything about my argument.

~~~
ashitlerferad
What about getting someone's key?

What about distributing your key?

What about backing up your secret keys on paper?

What about binding your primary secure key that is usually stored in a safe on
a Yubikey with secondary keys stored on Yubikeys you carry around with you?

What about revoking a secondary key after a laptop or Yubikey got stolen?

Perhaps you see where I'm going with this :)

The problem domain is just complex.

------
joeyh
If you're like me and gpg --export -a $KEY is 3000 lines of output due to lots
of signatures on your key, try:

gpg --export-options export-minimal -a --export $KEY

I guess github wants to associate particular accounts with keys, but it seems
they could save a lot of cut and paste bother if they supported importing keys
from the keyservers.

~~~
dochtman
I actually tried to upload my 1800 lines out of output, and GitHub fails to
parse it.

Was thinking exactly the same thing wrt keyservers.

------
coroutines
I'm happy about this but I thought signing commits wasn't a good thing to do.
Linus wrote a lengthy post[1] on this saying you should only care to sign
tags.

(I'm not a security person)

Read svckr's comment below and link #1 - what I was saying here before my edit
was wrong. :D

1: [http://git.661346.n2.nabble.com/GPG-signing-for-git-
commit-t...](http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-
td2582986.html) (2nd post)

~~~
svckr
I'm not 100% sure what you're saying here, but in the post you linked, Linus
seems to be referring to a _hypothetical solution_ where you're not signing
the SHA of a commit but some subset.

When you use Git to sign a commit or a tag, you vouch for the SHA of that
commit or tag; i.e. the whole history of that branch up to that point,
including author names and email addresses.

The point Linus is making is not exactly one of security. The problem you get
when signing commits instead of tags is that the signatures become part of the
branch's history and both (signature and history) become inseparable. You
can't re-sign a commit without re-writing all the commits that follow. If for
example your keys were compromised, you invalidated them, and want to re-sign
your repo with your new keys, you'll have to change each and every commit.
With a tag, you'll just update the tags and the rest of the branch remains
unchanged.

I hope, together with the thread you posted, this at least makes _some_ sense.

Back to GitHub: I think this is a nice UI for displaying signatures in the
history view. Assuming you can trust GitHub to really use _your_ public key
for validating (hat tip to fabulist) I don't see an issue with making that
information accessible via the web. More importantly, they also display the
"verified" badge on the "Releases" page where your tags appear.

~~~
coroutines
Yeah, I think my understanding is flawed - but trust in the Linus :D He has
some affiliation with git or something..

(thank you, kind expert)

------
616c
I was amused, after discovering Monotone through the I2P project that you can
sign your commits in git too (although in a SCM not written in C++, look
around for that famous Linus rant). I was well on board with the idea, like
signing my many emails, but even as a rank amateur I have nightmares of waking
up like this guy.

[https://mikegerwitz.com/papers/git-horror-
story](https://mikegerwitz.com/papers/git-horror-story)

So I would love tarballs and other things signed, and I do not want to be one
of those whiny moochers, but imagine the backlash you get as thankless free
software developer when you bork your tag sign or mess up one commit and
people through you under the bus, because you cryptographically agreed to it?
Haha.

~~~
joeyh
If you're reading that as an argument against signing git commits, I suggest
you re-read it.

~~~
616c
I mean, my comment was partially in jest. I check gpg.asc probably more than
the average, but not as much as a well-respected Debian maintainer. :-)

By the way, I am increasingly interested in trying to wrestle my VMs and
various boxes into order. I am tired of failing to learn different DSLs for
automation and love the pure Haskell of propellor, which is your tool for
managing Debian boxes.

[http://git.joeyh.name/propellor.git](http://git.joeyh.name/propellor.git)

Part of its cleanliness a la Haskell (which I doubt I can ever learn, but
applying it to a task like this makes it seem tangible), is you have signed
configs and you encrypt your own config into the repo (with cute patches
removing this folder will get my ire comments in the docs).

It is very refreshing and honest, like your other software. Hats off to you,
sir.

------
tombert
I'm not asking this to be critical, I'm asking because I'm genuinely confused;
how is this any more authenticated than just a password? Presumably anyone
with your Github password can go add or change your GPG keys if they wanted,
so how would it make you any more verified?

~~~
MBlume
Anybody can push a commit to a git repo with Linus Torvalds name and e-mail on
it. With GPG signing, they can verify that the claimed author signed off on
the commit.

~~~
cyphar
Except that's not how it actually works (you can push fake commits to _your_
repos). If someone can log into your account (to be able to push fake commits
to the account's repos) they can also add their GPG key. The point is that no
additional security is added by this feature.

~~~
MBlume
Without this feature, I can push commits up to my repo and claim they were
written by you; with this feature, people can tell whether you signed off on
those commits.

~~~
cyphar
So what? That implies that someone should believe someone when they say "look,
the email address on this commit says this person's name -- it must be that
person!". This all comes down to repo ownership. In your fork of a repo, you
have the ability to fake any history you want. Why should that bother me?
GitHub should stop auto-associating emails to usernames -- that's the _actual_
problem here.

------
r3bl
Am I the only one who thinks that, at this point, this has become and head on
race between GitHub and GitLab?

I might be wrong, but it sounds like an incredible coincidence that two
companies that haven't really made any noteworthy features on their platforms
in a long time are starting to release noteworthy features on an almost weekly
basis.

~~~
connorshea
Disclosure: soon-to-be team member at GitLab

I'd argue GitLab had a late start and has been making significant progress
since it started, and based on their Changelog they've been developing a lot
of new features for the last year and a half at least (every .x update is
released monthly on the 22nd): [https://gitlab.com/gitlab-org/gitlab-
ce/raw/master/CHANGELOG](https://gitlab.com/gitlab-org/gitlab-
ce/raw/master/CHANGELOG)

Personally, I definitely have a fairly competitive attitude towards GitHub,
and I'm motivated to push faster whenever they release a new feature :)

So yeah, competition is awesome :D

------
jasonjei
It seems like it addresses Linus's complaint about author verification,
especially needed with a mission-critical project like the Linux kernel.

I wonder if GitHub will have out-of-the-box support for pull requests by
email. That would be wonderful.

------
sarnowski
That is great news! I hope they will also go the next tiny steps soon:

1) as another commenter already pointed out, I would really like to see an
"unverified" badge instead of the "verified" to make GPG signing the default;
everyone should really be aware that all commit metadata like author and
committer are completely voluntary and you can lie as you want.

2) Please, add another merge restriction that only allows commit
pushes/merges-to-master with GPG signatures. This allows me to fully verify
future git repositories.

~~~
matt_wulfeck
That would require the --sign flag with every commit would it not? That sounds
like a pain. I would like git to automatically sign my commits if that were
the case.

~~~
sarnowski
You can set up the --sign flag in your local gitconfig.

    
    
        git config --global user.signingkey $GPGKEY
        git config --global commit.gpgsign true
    

In general, since you definitely do not want to upload your key material to
GitHub, you won't be able to use the pull request merge button and the new
squash button. This means, your pull requests need to be fast-forwardable,
else you cannot merge (as this merge would be unsigned). Also, instead of
using the squash button, you would need to squash the commits on your local
machine and push the newly signed squashed commit again. It comes as a cost
but it also leverages the decentralized nature of git: you can do everything
locally and sign locally so you do not need to trust someone else.

~~~
joeyh
git can sign merges.

~~~
sgarman
Right, but GitHub can't unless it has your private key which it probably
should't(if it's password protected) but that's a discussion for another time.

Many people use the feature on GitHub to manage their projects like the merge
button.

~~~
nickik
Their are two solutions.

1\. Develop an browser API that can request GPG operations. Something like
they are doing now with U2F

2\. Github could pop up a script that can be copy pasted into the command
line. The same way Keybase does it when you don't upload your private key

------
0X1A
Got an error: "There was an error parsing that key. Check that the key is
valid and try again." Cool.

Edit: It seems to like my key now...?

I've been signing my commits for at least a year now so it's nice that they
added this. I think it adds another layer of author verification other than
maybe SoB.

------
mfincham
Here's a signed commit I pushed in January to see if they'd recognise it:

[https://github.com/fincham/test-signed-
repo/commit/9d6e807d9...](https://github.com/fincham/test-signed-
repo/commit/9d6e807d9e34c60e79659433280a8b25b144007a)

Now shows a little "Verified" badge. Very nice!

------
dorfsmay
This is huge! Not so much because of signing software, but because fairly soon
most devs will have setup gpg and you'll be able to easily find their pub key
and trust it!

~~~
nickik
Hopefully they will all start to use Keybase. Prove that their github key is
the same as the one used on twitter and the same that signed their binary.

------
codemac
Anyone successfully get a workplace to have signed commits?

I've struggled to describe the _wins_. The risks are risks a lot of companies
have to take on anyways due to other parts of their infrastructure, and
generally end up ameliorating with signed blobs/releases.

~~~
michaelt
At my workplace we tried signed hg commits for a little over a year.

Perhaps it was the relative inexperience of our team, coming from our
subversion background, or it might be that we didn't adopt the best tools out
there, but it was a lot of work for largely hypothetical benefits.

We had a system involving a third-party extension to hg, and an agent that was
supposed to work on Windows, Mac and OS X - but it never seemed 100% reliable
on any of those platforms. We were also inexperienced enough that if, say,
someone committed something while their signing was set up wrong we weren't
able to figure out how to retroactively sign the commits. We also used x509
certificates issued by a central corporate IT team that issued them manually,
and expired the certificates annually without automatically issuing
replacements.

I'm sure some of these issues were with our team/organisation rather than the
tools themselves, but when the opportunity arose to switch to gitlab with no
commit signing required whatsoever, we switched immediately.

------
Perceptes
It's a nice feature to add signature verification to the UI, but it does leave
out the trust aspect of PGP. Showing a green "verified" badge may be
misinterpreted by users who are less familiar with PGP because they may think
of it as meaning "you can trust the authenticity of this commit," which is not
what it actually means. GitHub can verify that the signature matches the
public key that the author uploaded to their account, but that's not actually
useful unless the person viewing the commit trusts that public key.

It would be great if it had three different badges to distinguish between
different things: perhaps a red "unsigned" for commits with no signature at
all and "invalid" for commits with a bad signature, a yellow "verified" for
commits with signatures that match the author's uploaded public key, and a
green "trusted" if the person viewing the commit has marked the author's
public key as trusted.

------
mavam
It's great to see efforts towards integration of strong cryptographic
verifications. But what I currently miss is something much simpler: SHA
digests for release tarballs. I've already contacted github support, but
apparently this concern never made it high up enough in their priority list.

~~~
zokier
If you are downloading the releases over HTTPS then do digests really add any
value at all?

~~~
cuckcuckspruce
Yes, because they allow you to have mirror sites. Serve the digest from the
main machine over HTTPS and distribute the tarballs from a CDN or mirror
network.

------
wclax04
Did this release cause the current outage?

------
kmfrk
I guess keybase.io wouldn't work with this, since you need the e-mail address
to resolve for verification?

~~~
Oompa
You can add emails to your GPG key. I added my normal committer email to my
keybase key and added the key to GitHub as well and all is working well!

~~~
tylersmith
Weird. I have my primary GH email address on my key but still says it's
unverified.

~~~
Oompa
Be sure the email you commit with is also on your key. May not be your primary
GH email address.

~~~
tylersmith
Seems to have just taken awhile for GH to show it as verified. Working now!

------
Gedrovits
It's all cool, but for example their own GitHub Desktop don't support this
yet. RubyMine (don't start the holy war please) don't support this.

So now it's not quite easy to sign the commits without using the console...

------
cgtyoder
OR, you could use already well-established key servers, e.g. pgp.mit.edu. Why
reinvent the wheel?

~~~
AdmiralAsshat
[https://pgp.mit.edu/faq.html](https://pgp.mit.edu/faq.html)

>Can you delete my key from the key server?

>No, we cannot remove your key from the key server. When you submit a key to
our key server the key is also forwarded to other key servers around the
world, and they in turn forward the key to still other servers. Deleting the
key from our server would not cause it to be deleted from any of the other
servers in the world and so this is not an effective way to ensure the
discontinued use of your key.

I discovered the above the hard way when I was testing an Android app called
OpenKeyChain, which creates your PGP key and, without telling you, uploads it
to several keyservers for "convenience". Since I was _testing_ the thing, I
used a private e-mail and my name.

As a result, real name is now inextricably tied to that e-mail address through
a keyserver that was ostensibly supposed to provide privacy...

Neither here nor there, but I mention it because the experience somewhat
soured me on the idea of non-deletable keys.

~~~
Spivak
So an Android app in no way affiliated with the maintainers of PGP, GnuPG, or
the key servers in question published your private information, that you gave
it voluntarily, to a by-design decentralized key distribution system and it's
somehow _their fault_?

You're publishing completely public information on the internet. Even in a
world where key servers will delete your key that doesn't really help you when
anyone has access.

The best you can do is mark your keys as invalid by submitting a revocation
certificate.

> If you still have the private key, you can use your PGP software to generate
> a revocation certificate, and upload that to the keyserver. The exact
> procedure for generating a revocation certificate varies depending on what
> PGP software you are using, please consult the documentation for more
> information. This will not delete your key from the key server, but it will
> tell people who download it that the key has been revoked, and should not be
> used.

If you're annoyed that unpublishing something on the internet is futile there
are a lot of government officials and celebrities who will sympathize with
you.

~~~
AdmiralAsshat
Surprisingly hostile reply, given that I made clear that I don't blame the
keyserver for this.

I did attempt to contact the app developers about their app's behavior--
unfortunately, the only method they provided was a mailing list, so, upon
having my first attempt at being discrete blow up in my face, I decided that
being forced to send an e-mail to a public mailing list in order to draw
attention the fact that I had inadvertently de-masked myself just seemed like
rubbing salt into a wound.

To boot, it seems like something of a stretch to put a privacy-conscious user
who misconfigured (or was unaware what the default behavior was, in my case)
his privacy app to be in the same boat as a G-man or a celebrity who took nude
selfies, don'tcha think?

------
robin__
I'd rather see this integrated with some simple signing tool like openbsds
signify.

------
qwyxzy
When pushing signed commits, the GitHub web interface doesn't reliably update
with the new commits. Anyone else experiencing this?

Edit: Actually, it may just be commits in general. Usually the interface
receives updates fairly quickly.

~~~
pietroalbini
[https://twitter.com/githubstatus/status/717464295454470145](https://twitter.com/githubstatus/status/717464295454470145)

~~~
qwyxzy
Thanks.

------
jxy
Considering a long term project, signing using a private GPG key does not seem
to be practical. What happens if the key expires? What happens if the key gets
revoked? Or stolen? Are you going to sign every commit again?

~~~
minitech
Just sign new commits with the new key. Signing a commit also signs its
history.

------
wilg
Looks like I have to do something special to get this working with GitHub
Desktop (for Mac). Seems that gpg installed through brew isn't recognized by
that client. Is it possible to use both?

~~~
mastahyeti
GitHub Desktop doesn't support commit/tag signing at this point. Sorry.

~~~
mrsteveman1
Hopefully will at some point, it's one of the few reasons I use SourceTree at
the moment.

GPG in Github Desktop would be a fantastic addition :)

~~~
alain_gilbert
Do you use the "git flow" feature of SourceTree ?

I have a hard time trying to sign my merge commit. (after a new release for
example)

I wonder if you were able to do it ?

~~~
mrsteveman1
Nope no git flow here sorry :)

Is it failing to give you the option to sign (UI bug)?

~~~
alain_gilbert
There is no UI that allows you to specify that you want the merge commit to be
signed.

And if you configure git to sign all commits, you get this error:

[https://confluence.atlassian.com/sourcetreekb/sourcetree-
com...](https://confluence.atlassian.com/sourcetreekb/sourcetree-commits-fail-
when-using-git-signed-commits-794199810.html)

~~~
standardhuman
For what it's worth, I had that same error message (OS X), and I managed to
fix it. After using homebrew to make sure my git was up-to-date and gpg was
also installed correctly, I told git where gpg is (for some reason, despite
being in my PATH, it wasn't registering?): git config --global gpg.program
/usr/local/bin/gpg

After that, I had to make a tweak to gpg so I didn't get another annoying
error. In ~/.gnupg/gpg.conf, adding 'no-tty' got everything working smoothly.

I agree that that was way too tedious, but it did work out. :)

~~~
alain_gilbert
It looks like adding the no-tty in gpg.conf fixed it :D

Thank you !

~~~
standardhuman
No problem. :) I'm glad it worked out for you!

------
mataug
Well finally ! I've been lamenting about signed commits for a while.

------
emilecantin
Just tried this, and apparently Github doesn't recognize my key... I have a
master key, and three subkeys (encryption, signing and authentication).

~~~
pietroalbini
If your commits aren't marked as verified in the repository, push a new signed
commit to that repo. Then GitHub should start marking your commits (even the
old ones) are verified. Apparently this needs to be done per-repo, it's not
global to your account.

I guess that's the way they check if you are the owner of that key.

Edit: clarified

~~~
emilecantin
I mean I get an error message when adding my key on Github:

> There was an error parsing that key. Check that the key is valid and try
> again.

~~~
pietroalbini
It accepted an ascii-armored export of my key (gpg --armor --export $GPGKEY),
have you tried to add that?

~~~
bruth
I did and it failed to parse.

~~~
berdario
same here, I tried with both gpg2 and gpg

PS: the problem was that I had multiple keys locally... but weirdly, now that
I managed to upload my correct one, my commits are still seen as unsigned

~~~
emilecantin
Apparently I had the same issue... I specified the key ID when exporting,
instead of the email address, and it worked!

~~~
berdario
Funny enough, in my case it was the opposite (but I have multiple keys for the
same email address). Also, the problem about the commit still appearing ad
unverified was just a temporary issue: by looking at another repository the
changes were verified correctly (I guess that github caches gpg output, and
doesn't reexecutes it with every page load, obviously)

------
jasonmp85
This would be even cooler if you could add signature files for release
tarballs in GitHub Releases.

------
leshow
im getting an error adding the key, and it appears others in this thread are
also.

'error parsing key'

------
seadog007
That's cool

------
joepie91_
I'm quite unhappy about this change, as it misrepresents how GPG is supposed
to work. The _whole point_ of using signed commits/tags is to not have to
trust the Git server... yet by relying on GitHub's "verified" badge, that's
precisely what you're doing.

This is security theater, and it's going to mislead a ton of people into
thinking something has been verified more than it could possibly have been.
Signature verification is necessarily something that the _client_ must do, not
the server.

EDIT: Would the downvoters care to comment?

~~~
Kerrick
These days the GitHub.com UI is developing into a full-fledged git client. You
can branch, commit, merge, move and add files, and more. I see this as another
evolution towards GitHub.com as a git _client_.

~~~
lmm
A git client that's running on hardware you don't control though. One of the
golden rules of using GPG is to never run it on any machine except your own.

