GPG signature verification
github.com
github.com
If this doesn't show that competition is good, I don't know what else could!
https://help.riseup.net/en/security/message-security/openpgp...
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.
Github could have a setting like "flag unsigned commits from me after $date" that allows this kind of policy to be communicated.
It's like someone is telling you that they always schnarkel their schnops with shaush, now that the cost of schnacking a schnill is a mere $75k.
After however many days, I pretty much understand all of what joeyh is saying, except maybe for how the social engineering part would work. Thanks Hacker News.
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.
"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"
git ls-tree -r HEADLinus Torvalds http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
NO ONE i know does this. Conversely, everyone expects to be held, and hold others, accountable for the contents of their commits.
We don't have second preimage attacks on sha1 yet, but thinking of keeping signatures separates only buys you flexibility (which is not used by most projects currently on github) and maybe a bit of performance, for a process that is much more brittle.
Also, with things like this:
> It also doesn't add any real value, since the way the git DAG-chain of SHA1's work, you only ever need _one_ signature to make all the commits reachable from that one be effectively covered by that one.
He completely misses the point: who's going to check after pulling that the whole history of dozen/hundreds of commits is legit? That might be the case for the Linux kernel gatekeeper, but not for one of the several small contributors to any project.
Let's not do some "appeal to authority" BS with a myopic post from 7 years ago.
> He completely misses the point: who's going to check after pulling that the whole history of dozen/hundreds of commits is legit? That might be the case for the Linux kernel gatekeeper, but not for one of the several small contributors to any project.
Git does that automatically for you. Git self-verifies the DAG (which is why it takes a while to warm up on the kernel repo because of the insane number of commits). So he's not missing the point.
1) It's unclear what we should sign on a commit, therefore we shouldn't. I'm not sure what to make of that.
2) Since a key may be revoked, any signatures should not go into the commit. Presumably Torvalds thinks that tags should be deletable, but commits should not, or something.
3) That if all commits are signed, then it become automated, and therefore somehow not worthwhile. Meanwhile, automated signing seems awesome because we know that at least the signer had possession of the key.
I can't really extract much more logic out of that post, and none of it sways me in the slightest.
This isn't about using GPG siged vs nothing, it's "GPG signed in the commit" vs "GPG signed commit and metadata".
The bit about revoking keys is also interesting. He's pointing out that if you keep the signature in the commit, you have permanently bound that particular signature with the commit data. It's mixing two different types of data into one storage location.
The alternative is using tags, which shadow the main branch. This way you have the option of using those tags, or you can create new tags (with new signatures) with a new key. This gives flexibility for the future.
> insults
I don't see Linus insulting anyone in that post. Explaining the problems with a method is not an insult.
> therefore we shouldn't
Is that post really that hard to read? I find it obvious that he is saying you should use the builtin signing with "git tag -s".
[1] It's worth observing that this is a comment from 2009; I'm curious if he has changed his opinion on SHA1 in over the last 6 years.
[2] -s, --sign Make a GPG-signed tag, using the default e-mail address’s key
Fuck that shit.
The other thing is that the SHA1 weaknesses are collisions. It's not likely to be possible in the foreseeable future to create a commit that matches an arbitrary hash - to generate colliding commits, the committer would need to generate the good and evil commit at the same time.
Before SHA1 is broken, you can't change things that I have committed, unless you have access to my account. If a SHA1 preimage attack becomes available, you can. If a SHA1 bithday attack becomes available (for the low low price of $75k, croudfund one today!), you can, by sending me some particularly evil forms of merge requests.
Actually, no. You need a SHA-1 second-preimage attack, which is vastly more difficult. However, even if there was one, it would cause git pull to fail, as downloading the objects would likely require terabytes of garbage data.
Consider the case of taking the SHA1 of a message only 1024 bits (128) characters long (shorter than a tweet, let alone this reply). There are 2^1024 such messages, but only 2^160 hashes. So on average, there are 2^(1024-160) = 2^864 ~= 1.2x10^260 messages of length 1024 that must share each SHA1 hash.
It would be a very interesting result if you could prove that you had some 1024-bit message that didn't share a SHA1 hash with any other message of length less than 1TB ~= 8x10^12 bits, and this property couldn't be true of very many 1024-bit messages, because this means you "take away" from the hash space of messages of length 1032 to length 8x10^12. If you took away just 2^140 out of the 2^160 hashes, for instance, we'd readily see hash collisions in those in-between sizes, because there would just be 2^20 hashes left. But even then, this special property you imagine would only apply to 1 in 2^884 ~= 1 in 1.2x10^254 of all 1024-bit messages so you'd have trouble finding one of them in the first place, and more to the point it's almost impossible that your victim would have selected one of these hashes that would require your hypothetical terabyte file to collide the SHA1 hash.
In theory, nothing I know forbids the possibility of finding an algorithm which yields a 160-bit solution within a few years. In practice, such an algorithm is tremendously more difficult (and potentially impossible) to find than simply finding a SHA-1 second-preimage attack, which is already vastly more difficult to find than a preimage attack, which is also vastly more difficult than getting a non-bruteforce collision.
It would certainly be a phenomenal achievement, however. We still don't have a practical preimage attack on MD5, 10 years after the first actual collision found…
Regardless, we're only now beating the first challenge after 20 years. It is likely to take more to go from there to a second-preimage attack, and more still to have it be a 160-bit solution within a practical amount of time. git will double its lifetime multiple times before then. Something shinier will have replaced it.
I'm not sure "terabytes" is justified either, but the point's a good one.
Apart from that, half the patches I prepare go out via git format-patch rather than a push and a pull request. So I'll need to confirm if the signature survives that workflow, and if it produces unwanted noise or other effects on development mailing lists.
Are there any efforts in writing a minimal version of it with a modern and flexible UI?
I imagine alternate pinentry implementations exist for other OSes as well.
Honestly the agent is better than it was (not that that's saying much). Other than that, GPG relies on one part-time developer - I'm sure contributions would be very welcome.
I have a key fob that performs cryptographic operations. Rather than use existing standards, GnuPG demands full control of the fob, making it impossible to use the same device for client certs on browsers, or for the VPN, etc. There are some barely maintained shims that get around some of these design flaws, but it's an extremely hassle to find the shims and to get them working.
GnuPG's agent also makes it quite difficult to use git remotely. Most of the code I write is on remote servers, setting up an agent to allow forwarded operations.
I think that it's time to move on from GPG, or fork it, or something. There's not much in GPG's implementation of PGP that I like.
It's the only mature implementation of the relevant standards (at least now that RSA inc. has demonstrated its nontrustworthiness). I've never known anyone have a bad word to say about the actual cryptography (and notably it seems to have been effective for e.g. Snowden).
By all means improve the agents and the integrations, and fork it if you think that will help. But keep the OpenPGP standard and keep the proven cryptography implementation. That part is worth its weight in gold.
Unfortunately after reading the source code and then reading the OpenPGP spec, I am convinced that most of the problem is actually OpenPGP. GPG is a bit of a hairball of a program, but it is faithfully doing what it is supposed to be doing.
Here is how I would describe the basics. Hopefully it will help you wrap your head around it. The bad part is that OpenPGP does not actually work this way. Consider this as "this is a way to view how it would work if OpenPGP wasn't completely insane":
- A key is composed of a private and public part. These are often referred to as "public key" and "private key"
- A key that one signs should actually be thought of as a certificate
- A certificate is just a bundle that includes a public key part, an "identity" (which is usually just a string, but can also include a picture), and a bunch of signatures. The signatures indicate that somebody believes that the identity is bound to the public key part (i.e. the string identifies the person who holds the private part of the public key).
- When you "sign" something, your signature is related to a piece of data (usually text). If someone has your public key part, they can verify only someone with the private part could have produced the signature. It is important to realise that you must sign something.
- When you "sign a key", what you are really doing is creating a signature for the identity string on a certificate and adding your signature to it.
- There are "master keys" and "sub keys". A "master key" should really be thought of as a certificate along with the private key part. A "sub key" is a public-private key pair with a particular ability (sign, certify, encrypt, or authenticate).
- You can create a certificate for your subkey that contains the public part of the subkey and is "certified" (basically signed) by the master key private part. This allows people to tell that your "sub key" certificate is associated with your "master key" certificate.
- Your sub key certificate has no identity information and is not signed by anyone other than the owner. To find out the identity of the person who owns the sub key, you have to have the master key in your possession and check the signature on the sub key.
- GPG makes a kind of "container" where it stores the master key certificate (which includes the public key part, the identity string (and possibly picture), and signatures of the identity by other people) along with the sub key certificates (which contains the public key part and a signature from they master key). In another place, GPG stores the private key parts that you may have for any master or sub keys.
Now go back to the GPG documentation and read it. That is how OpenPGP specifies that you must actually implement it. It would be nice to write an implementation that was simpler (possibly as I describe above), but it will always be a slightly leaky abstraction. And even my (much, much less confusing IMHO) description above is still ridiculously complicated.
Anyway, I hope you found it interesting.
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?
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.
You need key rotation if you want security, so you need master keys and subkeys (or you'll end up reimplementing them by hand with conventions that everyone will interpret differently). Multiple identities on a key are I guess not strictly necessary but they're a very useful feature. You absolutely need the ability to sign other people's identities. You need to be able to sign and encrypt both text and binary (and do symmetric encryption), and export the result of everything in both text and binary. Smartcard support is a very good idea. Agent support is vital. What things do you think GPG should cut?
> You want this as a library that's impossible to misuse and a nice CLI on top.
Agreed. A rock-solid OpenPGP library would be great. I do think that's one place where there's a lot of real room for improvement.
> 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.
IIRC: developer, singular, unpaid and part-time. Also GPG is 20+ years old and doesn't want to change the CLI radically so as a) not to disrupt existing users b) not to disrupt existing scripts.
A frontend or alternative with great UX would be really useful. But who's going to pay for that work?
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.
This same attitude may also explain the tendency to reinvent things like rsync and other tools that have accumulated a large set of options over the years.
GPG's particular command-line interface is still a counterintuitive mishmash of stuff that essentially boils down to having to look up a tutorial every single time I want to do anything related to key management. I've actually been known to ask people to email me just so I can fire up a mail client with Enigmail and have it auto-fetch the key into my keyring and set trust on it through their interface. Which, while not great, is light-years better than GPG's native key-editing interface.
Regardless, just like any feature-rich technical library, this is easily solved by a front-end. For example,
> Enigmail
...is an outstanding front end for many common uses. Unfortunately, the idea of writing a better UI front end for GPG - possibly many, specialized for various tasks - just like we've done for every other complicated piece of technology, it seems like everyone says "it's too complicated" and writes off GPG entirely.
> native key-editing interface
While I agree that interface is not the best (use Enigmail), I don't necessarily find it hard. It's very unrefined, tedious, and can be very annoying.
Note that GPG is not a technical library. The primary "library" for using GPG consists of some functions that system() out to GPG and pipe data back and forth. I think this is a big impediment to getting better frontends (particularly on platforms other than linuxlike desktops).
This is the same as saying "hard".
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.
Was thinking exactly the same thing wrt keyservers.
(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... (2nd post)
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.
(thank you, kind expert)
I was thinking it'd be nice if you could set a signing policy on GitHub - either all commits are signed or none are. A mixed situation just leads to harmful confusion. You would still need to verify sigs yourself, but if they're available for every commit this does still save you time before creating the signed tag.
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.
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
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.
For folks who haven't seen the Torvalds "graffiti" on github, it's critical to distinguish here: "anybody can push a commit to /their/ git repo".
They do verify it against the email address on the key, so anyone who made it show up as verified had access to your github password and was able to read an email sent to you. But also, if you don't trust github, you have the option of checking the signature directly and verifying the key thorough any of the other OpenPGP mechanisms.
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.
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
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
I wonder if GitHub will have out-of-the-box support for pull requests by email. That would be wonderful.
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.
git config --global user.signingkey $GPGKEY
git config --global commit.gpgsign true
Many people use the feature on GitHub to manage their projects like the merge button.
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
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.
https://github.com/fincham/test-signed-repo/commit/9d6e807d9...
Now shows a little "Verified" badge. Very nice!
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.
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.
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.
So now it's not quite easy to sign the commits without using the console...
>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.
I think a much better system is using keybase (with your GitHub identity linked to keybase), and then checking the gpg signatures using git locally. GitHub's setup has no tangible benefits (if you can log in to an account and therefore can push to your own repositories and make pull requests as yourself, you can also change the trusted GPG keys). The only case where it might help is to show that a commit on someone else's repo isn't you. But surely that's something people already assume?
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.
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?
http://pool.sks-keyservers.net/pks/lookup?op=vindex&search=p...
Yes they do. It's called "the web of trust" and has existed for quite a long time.
The SKS keyserver pool was recommended instead.
Edit: Actually, it may just be commits in general. Usually the interface receives updates fairly quickly.
GPG in Github Desktop would be a fantastic addition :)
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 ?
Is it failing to give you the option to sign (UI bug)?
And if you configure git to sign all commits, you get this error:
https://confluence.atlassian.com/sourcetreekb/sourcetree-com...
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. :)
Thank you !
Ah ok, I see what you mean. I don't think theres a way to have rebase re-sign things inside SourceTree either, I run in to that one constantly and have to open a terminal.
I guess that's the way they check if you are the owner of that key.
Edit: clarified
> There was an error parsing that key. Check that the key is valid and try again.
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
'error parsing key'
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?
Generally the general feeling here on that word has a negative connotation associated with things like the TSA and mandating backdoors (something I agree with). However, I do not believe (and the majority of HN, most likely) that GH is actively being malicious adding this feature in.
You do have some points: you should only do GPG verification on machines that you trust. This is true, I think we can all agree. However, you say it may train users to ignore checking locally, which remains to be seen. Further, there are some counter points that you're not considering:
(1) this move gives huge publicity to gpg signing of commits, which hopefully encourage more people to sign their commits and tags, which hopefully should promote better security.
(2) Absolute trusted hardware is hard to come by these days. At the moment, we do not suspect that Github is actively working against us. We can therefore trust GH to display the correct verified tag, for now. If you want to go down the absolute security route, you'll realize that you absolutely cannot trust your own machines either (at least a majority of us cannot). This brings you to a tricky situation where there is no where safe to run GPG. Then what?
I think the pessimistic view you presented shares similar ideologies as the view that iMessage can be easily broken because Apple can simply swap out keys. While I agree that this is a concern, I still think that this move by GH is overall positive, just like iMessage is overall a positive step to secure messaging. Incremental steps are good imo and we'll see where this takes us.
EDIT: In this case, the 'client' would be your browser.
> it's going to mislead a ton of people into thinking something has been verified more than it could possibly have been
What specifically do you think people are going to think has been verified?
Given that both git and openpgp are designed to be distributed and resistant to attacks on any centralized party, that's a reasonable model to have in your head when checking an openpgp signature on a git commit.
> What specifically do you think people are going to think has been verified?
That my ultra-paranoid friend John who doesn't even use web browsers has signed commit xyz - that's what I'd think when I checked the signature in command-line git. Whereas seeing the "verified" picture in the GitHub page conforms that John signed commit xyz or some script kiddie found a vulnerability in github's rails app or the US government sent an NSL to GitHub or ...
For many threat models that's still a very useful guarantee. But it's a very different guarantee from what you get when checking a gpg signature on a git commit locally, and that can easily be very confusing.