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!
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.
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.
Apologies for being completely off-topic, but reading this comment gave me a flashback to whenever it was when I started reading Hacker News. Try to imagine that you know nothing about version control or cryptography and then read the above comment.
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.
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.
If you sign every commit then someone would have to find a collision for one object such that all subsequent commits that touch that object still made sense, no? Which would make an ongoing compromise harder.
That assumes that you verify the contents of EVERY commit since the last tag, when you sign a new tag.
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.
> > 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.
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.
Once you strip away the insults, what's left appears to be:
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.
While I think that Linus is relying too much on SHA1[1], he makes several good points. His primary concern is the difference between adding signed content as part of the commit vs using "git tag -s"[2] which also signs the commit with GPG. The difference is that "git tag -s" includes the DAG metadata so the git history itself is verified.
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
Ah, the curse of being Torvalds. He writes 600 words clearly explaining his position in an educational manner, and near the end, says an action is 'stupid' (not a person!) in one single sentence. This is characterised as "once you strip away the insults". You've just insulted Torvalds more than he insulted the person he was responding to; hardly a position to be moralising from.
Git's use of SHA1 is explicitly not intended to provide any security (per Linus), so this argument really doesn't make sense. On github, right now, I can commit as you all I want, no exploits required, and that seems like a much more pressing reason to sign commits.
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.
The existence of things that claim to have been committed as me, with no proof and not in the history of my master branch or a released tag, is irrelevant. My users use my release tags, and my master branch, they don't use random commits you make "as me" elsewhere.
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.
> If a SHA1 preimage attack becomes available, you can.
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.
nah, "terabytes of garbage data" is unlikely to be required.
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.
Like I said, finding a SHA-1 second-preimage attack is vastly more difficult than finding a SHA-1 preimage attack. You can claim to have found one as soon as you have any means that is not brute-force which produces a colliding preimage, no matter how practical it is (ie, it could require the use of humanity's entire energy spending for a thousand years, and more disk space than can be built with the Earth's atoms).
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.
ISTM if an attacker had the former she wouldn't need the latter? That is she would produce the evil commit and its hash herself, and then sign that hash. I may be misunderstanding something?
No, just the header of the commit (i.e. just the SHA-1) is signed. The signature you used on the valid commit would work if tacked onto the malicious one.
Is that $75k for a preimage attack? You would need to generate a collision that could be reasonably interpreted as a valid commit. It's my understanding that preimage attacks against SHA-1 are still considered to be impossible, even for a state actor.
The main thing stopping me from doing the same is that I do my work on three different machines: my personal laptop, my work laptop, and a build server in a lab. Those represent three different trust levels. So I'd need to make two more GPG keys than I currently have, and handle key management, which at the moment doesn't yet seem worth the trouble.
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.
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?
I use a Yubikey 4 for this purpose, signing individual commits then becomes "physically touch the key to sign" (after you enter the pin one time) rather than entering a long passphrase.
Something more like openbsd's signify[1] tool seems like it would be a nice signing tool for git commits. Signatures and keys are small, due to use of ed25519[2].
What's up with the dead comment? I find GnuPG's command line interface to be on par with most other programs and don't have any particular troubles signing / encrypting / decrypting messages or files, symmetrically or otherwise.
Not that I know of. Everyone who's enthusiastic about modern crypto seems to want to throw out the proven cryptography baby with the horrible UX bathwater :(.
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'm not so sure that contributions would be welcome. When I've come up against limitations, and go search through the mailing lists to see what's been done, I find that ideas and code have been rejected.
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.
> 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.
I spent a considerable amount of time a few months ago trying to figure out GPG. I've used it for years but never really understood what it was doing. Part of the problem is that the documentation is really misleading in certain places (and conflates many different things attaching the label "key" to them).
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.
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.
> Essentially you want 3 operations. Generate keypair, encrypt X with key, decrypt X with key.
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?
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.
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?
I have little direct evidence, but I suspect the problem is a set of programmers that hate the command line and never learned to rely on man pages. When they try gpg, they try --help and see the giant list of options, and immediately panic.
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.
I consider myself pretty comfortable with command lines, given that I more or less live in a terminal window for work purposes.
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.
Is the command line interface that is confusing? Or is it that the crypto jargon is confusing? I suspect the latter, maybe?
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.
> Regardless, just like any feature-rich technical library, this is easily solved by a front-end.
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).
That is an order of magnitude more effort than most people are willing to put into it. Try teaching a not-computer-savvy relative to use it and exchange email with them.
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.
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
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.
I would add that you shouldn't trust GitHub not to lie to you, and verify signatures for yourself. One need not attribute malicious motives to GitHub in this scenario; they could get hacked, served with an NSL, successfully man-in-the-middled, or inadvertently hire a bad actor.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
How would GitHub even authenticate against a password? Not everyone has an account (and some people have more than one account), and it's very common for one person to push someone else's commits. This gives them an interoperable way to verify commits, even if those commits were originally made on Bitbucket or somewhere else.
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.
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.
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 :)
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.
GPG signing every commit has dubious benefits. You have to rebase your entire history if your GPG key is compromised. It also increases the footprint of the repo, and having signatures for more than HEAD is redundant (if the repo state is valid, then the DAG has been verified already). The best thing to do is to sign tags, IMO.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
>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.
PGP is modeled on physical mail: content is private, but identity is very public. (I mean, the very idea of signing something is inextricably linked to having a public identity - if you're signing commits on github then you're creating an identity that stands by those commits).
I'd argue that's a feature, especially with something as intractable as a commit history. If you sign a commit today, and the only place that stores your key is GitHub (where you can delete your key), I can't verify that signature forever.
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?
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.
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?
Anyone can create a random key with a random email. See all the president@whitehouse.gov addresses on the keyservers. So if they used the keyserver network I could just make a fake key for anyone I want to impersonate and upload it. Github has no way to authenticate which keys are good and bad if they only use the keyserver network. So they have you upload the key on their site to implicitly authorize the key as one that you (the person with the github account, or at least its password) consider valid.
> Github has no way to authenticate which keys are good and bad if they only use the keyserver network. So they have you upload the key on their site to implicitly authorize the key as one that you (the person with the github account, or at least its password) consider valid.
Yes they do. It's called "the web of trust" and has existed for quite a long time.
I recall a discussion a while ago (on the cryptography list, I believe) where it was mentioned that pgp.mit.edu is often out-of-date, stops syncing, or is otherwise broken.
This is providing that information in the GitHub web UI, which previously did not mention that if particular commit was signed. It has always been available via well-established key servers using the git/gpg command line tools.
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?
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?
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. :)
> There is no UI that allows you to specify that you want the merge commit to be signed.
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.
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.
It shouldn't be necessary to push a new signed commit for old ones to start showing the "verified" badge. We do cache some of our templates though, so it may take a while for some pages to be updated.
There is a known bug where leading whitespace can cause the key to not be parsed. Also, check that you're only trying to upload a single key, and not your entire keyring.
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
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)
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.
I didn't downvote you either. I agree with your premise. However, I think using the words "security theatre" is inflammatory and overly pessimistic, which is why you're getting downvoted.
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.
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.
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.
That really doesn't matter. It doesn't run on your own system under your own control, and thus, for security purposes, it can't be considered a client.
EDIT: In this case, the 'client' would be your browser.
(I didn't downvote you, but) Just because it doesn't protect against one class of attacks you have decided to be care about it isn't "security theater" if it helps against others. If your threat model includes "I don't trust GitHub/their servers", then yes, you obviously have to verify offline.
> 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?
> If your threat model includes "I don't trust GitHub/their servers", then yes, you obviously have to verify offline.
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.
If this doesn't show that competition is good, I don't know what else could!