Exactly! It would be nice if keybase.io had a simple click this button to publish your public key to common key exchange servers. But it isn't that hard to do it manually.
The problem is that AFAIK they don't tell their users that anywhere, and I often encounter people that only have their key on Keybase and it's a real pain to import their key.
OK, I clicked. Where is your email address? Was that stawros or stavros? Do I really need to copy the key or .asc address, wget it and import? How do I know if that's your latest key? Did not you revoke it last week and forgot to update keybase but didn't forget to update your blog? THERE MUST BE AN EASIER WAY!
Keybase has a pretty good command line tool and commands very similar to ones in the article we are commenting upon can be used to grab the public key of a Keybase user using just their Keybase username.
It should probably be easy to presume that if a user gives you their Keybase username they are telling you it's the easiest way to get their most up-to-date key(s) and revocations and that they are actively managing it. (Pretty much the same assumption any time anyone ever suggests to you a specific keyserver over just a fingerprint and keyserver roulette; that's probably the keyserver they actively check/update/revoke and will be the timeliest.)
Sure. It would be great if they supported both. The suggestion is to use their tooling because it provides a lot of added value, but yes, it would be great if they also provided a standard "dumb" PGP/GPG keyserver, too.
Maybe consider contributing to the effort?
Quick searched turned up several issues tracking the question:
Did not you revoke it last week and forgot to update keybase but didn't forget to update your blog?
Revocations are a big problem.
As browser PKIs have demonstrated, revocation lists are basically insane and absolutely Do Not Work at scale when keys are able to live for years.
The endgame with browsers was that the cert revocation lists basically aren't checked. Hooray.
More fundamentally, revocation (even if it was scalable) is fail-unsafe. If someone can block your connections to revocation info sources, they can get you to perform unsafe operations. It's not a stretch to say that this is an absurd problem when we're trying to roll out secure cryptosystems: a network DoS should not crack open my security.
This is something TUF -- http://theupdateframework.com/ -- tackles with their timestamped re-assertions. It limits the amount of time that you can fail-unsafe by after seeing a revocation... to a tunable parameter, perhaps days or even hours, instead of years. At the same time, you get to keep your long-lived keys (you don't have to constantly update everyone on new keys).
We should learn some tricks from TUF for our personal comms PKIs. It would solve a lot of problems.
«I don't really get what keybase.io is supposed to solve»
Keybase was built to solve the "web of trust" bootstrap problem [1] by leveraging the web of social media profiles a user typically has with simple replicable proofs of social media identity.
[1] Arguably the hardest problem in PKI: how do you get user to trust that a public key is for the right person? In the classic PGP/GPG web of trust you do things like "key signing parties" and physical in real life interactions and deciding your threshold for how far you trust the friend of my friend signed this key. In the Keybase model you can see that the key (or family of keys) are tied to a certain combo of Twitter, Facebook, HN, et al accounts/profiles and generally trust that the person with all those accounts is the person you are trying to communicate with.
That would be the second hardest problem in PKI: key escrow and key management. The answers to the questions most average users have like: What do I do if I lose my machine? If I'm logged in from the library or work or my friend's PC? If I use multiple machines every day?
When the "right" answer includes "Print out this long thing, put it in a safe deposit box, and pray you never have to type in this long string of numbers", you immediately lose a lot of potential users; it doesn't quite fit the "Grandparent test" (could your Grandparent use it?).
Absolutely there's a trade-off in trusting a 3rd Party key escrow, but there's an immense usability benefit to average users that want something easier to do and "some security" really can be better than "no security", even if a lot of hard-line paranoid wonks have good reason to believe otherwise.
My grandparents don't even use email. I don't think we should be setting them as the lowest common denominator for security. Some things that are worth doing require a little bit of effort.
You have have to consider the lowest common denominator in security. You're security it's only as good as your weakest link. Say you have an emergency and your grandparents need to email your PII to a hospital. Can they do it securely? You need to email some PII to them. Can you do it securely? Some security for all is better than no security for most, hence the "grandparent test".
I think it would be even better if we could design systems where it isn't even necessary for a family member to "email your PII" to anyone. That's a terrible idea in almost any situation, regardless of your security.
Yes. Keybase is trying to make a walled garden for itself.
I got really frustrated by this a couple weeks ago when I needed to get a key from a contractor but it was only on Keybase, which at the time I thought could be used as a GPG keyserver.
Can someone please give examples of key-exchange services or server applications? I am getting a bunch of Microsoft exchange results when I try to google it.
Things to know about keyservers such as SKS: There is no way to remove keys or a way to really delete information. Uploading to know server will propagate that information to all SKS servers in the network over time.
You don't need keybase to sign your commits. Any standard and key-exchange compatible pgp/gpg client will do. By using keybase you're just adding more work for everyone.
Keybase makes it really easy to sign commits. By using keybase you get to manage keys and sign quickly. gpg will take hours of reading with its non-intuative cli. You're making less work for yourself.
Gpg is the flossing of encryption. It has great efficacy and terrible efficiency.
I think the cooler part of keybase.io is that it provides a platform for authenticating your separate social accounts (reddit,twitter, etc...) along with websites and github. That's pretty neat, and I can't say I've seen something like it before.
Keybase would prefer to handle your private key too. You can work with your key offline too, but you have to be aware that this is what you want when setting up- and it's very much not the happy path, so the site will not fully work as you might expect.
Not faulting them, they provide the steps needed, but it might be annoying enough for some people to start uploading private keys.
I've signed up a long time ago (yay early adopters I guess), so I can't comment on the sign up process or setup with your own GPG key nowdays.
But their website works 100% and provides all the functionality if you don't let them host the private key (they give you an easy-to-inspect snippet to paste into your terminal that downloads/signs/uploads things for them. Note, it does do anything when you paste - you need to manually hit enter)
It works fine; you just have to know up front to not just click "yes" for everything during the sign-up process. Not a big deal for people who already know how GPG works, but the whole point of Keybase is to make it easier to use for people new to crypto, and that audience can't be expected to understand that the default settings are a terrible idea.
You can but last time I used it the first option you were presented with was giving keybase your key. I don't know if that's changed years later because I closed the app at that point, I wasn't interested in using or encouraging others to use such a thing. The guy pointing this out was downvoted and I frequently see the fact that its possible to not give them your key presented as somehow making it acceptable that they ask for it.
Please note that this was initially written as a reference for myself, being relatively inexperienced with the keybase client and gpg tooling in general. There are certainly different ways to accomplish the same and you don't have to use keybase, but I wanted to. Please keep this in mind.
Yeah, and even though I had set this up myself just a few minutes before I submitted PR #3, I ended up committing on the web UI as well, with no signature :D
But what do you do with the signatures on the signed commits? It is of some, limited value, to GPG sign because it does provide a little bit more of "John Hancock" for a release, but how does this work in a continuous integration environment? Does the CI server reject commits that are not properly signed? Does the server refuse to run unsigned or incorrectly signed Git deployed code?
It provides a confirmation that the person who's name & email are on a commit actually made the commit. I can configure my instance of git to make commits as "Linus Torvalds <torvalds@linux-foundation.org>", but only the real Linus can sign them with a publicly-verifiable GPG key.
Keybase desires to act as a keyserver and public identity record, keeping your aggregated identity, and a backup of your public and private key pair. The latter is (read: should be) encrypted and only accessible to you. They make that optional, though, and will happily keep track of only your public key. It is absolutely optional, and it exposes you in one critical way: You have to take Keybase's word that they cannot (and will not develop the ability to) access your private key, even though it's on their servers.
I don't use that feature, because I can't see an advantage to it. I can keep a paper copy of my private key in a safety deposit box, if I'm worried about having a secured backup of it that's out of my hands.
You can use it to do actions on the Keybase site by typing in your decryption password. Attack vectors: Keybase site code gets replaced with something malicious, now they have your key password and decrypted private key.
You can also do everything on the command line without trusting Keybase's server or their frontend JS.
Another problem: if their storage or a backup is compromised, the attackers can brute-force passwords offline without rate-limiting.
In some ways that's worse than actively trojaning their JavaScript since there's no possible way for the target to know that's happened whereas the fronted at least has the low but non-zero chance of someone noticing the malicious code.
I'm not sure keybase does this by default, but make sure to upload your key to a keyserver such as MIT's (https://pgp.mit.edu). Otherwise, git will complain that the signature is invalid when doing `git log --show-signature`.
Github doesn't complain for me, so I can only assume that it does this itself. What I did was grab my key from keybase and inserted that into my local keyring, then uploaded that to my github.
This is only true if the person looking at the repo doesn't have a copy of your key locally. It's important to remember that all of these tools work offline and don't require some web 2.0 service to operate. :P
By the way, most users get around 20 free invites shortly after signing up. If one of the links above opened your account, why not share five of your own invites afterwards?
Displaying the signature in the web UI is actually the only feature from GitHub I miss when using GitLab. It's not a huge deal, but it gives me a warm-and-fuzzy.
And as noted nearly every time this 7-year-old comment by Torvalds is mentioned, this is of course technically correct due to the properties of git's Merkle tree, but completely impractical as far as the human implications.
Consider: You've just written 20 lines of code, and you're creating a commit. Can you validate that all 20 lines were created by you before you commit?
Now, consider that you're looking to create a tag for version 2.0, coming from 1.4, with a net 4,000 new lines of code. Can you quickly and confidently validate that all 4,000 lines of code are as expected?
Clearly, the frequent, small validations are much simpler than infrequently signing huge releases. When integrity matters and humans are involved, small batches win.
If you autosign every commit then you aren't validating anything anyway. All that means is you have another mindless process running automatically in the background. So what's your point?
Linus has a point, but it's not without flaws. Linus is saying that it makes you complacent, and doesn't prove anything about any release, and that you should sign golden commits. He says this because only what is shipped needs to be trustworthy; and the value of a signature degrades with the more things it signs.
This raises the question, though; how do you know when you reach that golden commit? Is the signer responsible for auditing every commit since the last signature, every line of code? If he doesn't, what does the signature prove?
That's what Linus has wrong; The signatures aren't about proof, they're about audit trail. For Linus and the kernel.org use case, this isn't necessary. They've already built tooling, and most importantly structure around the code auditing. Every commit that goes into the mainline is somewhat audited by Linus himself. There's a whole layer of competent release engineers in front of him. Code doesn't make it onto the kernel.org repos without having been trusted by a very select group, and doesn't get pulled to master without the word of God.
I suggest, for the average developer, having two keys. One online, to verify that the commit was developed on your computer. One offline, that is only used for releases. One for audit trail, one for golden.
I was also told that having a signature on every commit makes pulling the entire repo take forever (because it has to validate every commit). Not sure how true that is.
While I don't know how bad the performance would be on huge repos, there is of course an option to turn it on or off (--[no-]verify-signatures.) which I believe is off by default.
Only signing releases is equivalent to saying "every bit of code I just released I trust and so should you". This means that you have to have reviewed every change to make sure someone didn't dupe you into signing a commit you didn't mean to.
Signing every commit is a much easier guarantee to make: "this change was made by me and I trust this change". In aggregate it's much better than just having signed releases (though of course you should sign releases in addition to this).
Somebody please explain to me: What's the point in signing on github when I can set the key on github itself (e.g. account gets compromised). A simple flag (on github's server) that is showing that my email on commit is the same as on the account would also do the job. What if my key is compromised and set a new one on github? What happens with my old signed commits?
Another question: We are mostly no airplane mechanics which need to sign everything of our work. Why would you give up deniability of doing something (with your signed key) without thinking about the consequences? I'm thinking of legal cases here (hey you signed your commit!).
Github can't verify you actually committed a change unless it's signed. You can set whatever email address you want on any commit.
They could verify who pushed it to github, since that action is authenticated, but restricting pushing other people's commits would break many workflows (eg, a bot pushing from a local git server), or a reviewer pushing code sent to a mailing list, or resolving conflicts in a merge locally.
You can also verify the GPG key independently of Github. Perhaps your CI system could verify all commits it builds are signed, and your deployment system could too. There's no need to use Github as the authoritative source for that sort of thing.
Is keybase.io still mostly useless because it is not compatible with other key-exchange servers and can't be easily added to Enigma in Thunderbird?
AFAIK keybase.io is not meant as a key exchange server. You should publish your keys using an existing exchange server.
Exactly! It would be nice if keybase.io had a simple click this button to publish your public key to common key exchange servers. But it isn't that hard to do it manually.
The problem is that AFAIK they don't tell their users that anywhere, and I often encounter people that only have their key on Keybase and it's a real pain to import their key.
How much of a pain is it? You just click on the fingerprint on their page, no?
https://keybase.io/stavros
OK, I clicked. Where is your email address? Was that stawros or stavros? Do I really need to copy the key or .asc address, wget it and import? How do I know if that's your latest key? Did not you revoke it last week and forgot to update keybase but didn't forget to update your blog? THERE MUST BE AN EASIER WAY!
Ehh screw that. I'll write it in plaintext.
It's right in the key!
Is this a failure of keybase? You import it as with any other key, "decrypt from clipboard" in your favorite manager, or similar.
I don't know, how do you know that with a keyserver?
Again, same as any other keyserver.
It seems that the frustration is with the PGP client, rather than keybase or the server, though.
Keybase has a pretty good command line tool and commands very similar to ones in the article we are commenting upon can be used to grab the public key of a Keybase user using just their Keybase username.
It should probably be easy to presume that if a user gives you their Keybase username they are telling you it's the easiest way to get their most up-to-date key(s) and revocations and that they are actively managing it. (Pretty much the same assumption any time anyone ever suggests to you a specific keyserver over just a fingerprint and keyserver roulette; that's probably the keyserver they actively check/update/revoke and will be the timeliest.)
Another example of the walled garden. You need their tool, whereas you can just use gpg with every other keyserver.
Sure. It would be great if they supported both. The suggestion is to use their tooling because it provides a lot of added value, but yes, it would be great if they also provided a standard "dumb" PGP/GPG keyserver, too.
Maybe consider contributing to the effort?
Quick searched turned up several issues tracking the question:
https://github.com/keybase/keybase-issues/issues/327
https://github.com/keybase/keybase-issues/issues/890
https://github.com/keybase/keybase-issues/issues/1266
Revocations are a big problem.
As browser PKIs have demonstrated, revocation lists are basically insane and absolutely Do Not Work at scale when keys are able to live for years.
The endgame with browsers was that the cert revocation lists basically aren't checked. Hooray.
More fundamentally, revocation (even if it was scalable) is fail-unsafe. If someone can block your connections to revocation info sources, they can get you to perform unsafe operations. It's not a stretch to say that this is an absurd problem when we're trying to roll out secure cryptosystems: a network DoS should not crack open my security.
This is something TUF -- http://theupdateframework.com/ -- tackles with their timestamped re-assertions. It limits the amount of time that you can fail-unsafe by after seeing a revocation... to a tunable parameter, perhaps days or even hours, instead of years. At the same time, you get to keep your long-lived keys (you don't have to constantly update everyone on new keys).
We should learn some tricks from TUF for our personal comms PKIs. It would solve a lot of problems.
I don't really get what keybase.io is supposed to solve, but it doesn't get in the way of importing keys into Enigmail.
If you are in Enigmail's Keymanager you can import from a URL when the content is well-formatted.
Examples that work:
https://keybase.io/snassar/key.asc https://pgp.samirnassar.com http://keys.gnupg.net/pks/lookup?op=get&search=0x69A75542488...
It would be nice if Keybase made the URL more easily "gettable" instead of hiding it behind 2 clicks.
Keybase was created by NSA to make pgp/gpg harder...
«I don't really get what keybase.io is supposed to solve»
Keybase was built to solve the "web of trust" bootstrap problem [1] by leveraging the web of social media profiles a user typically has with simple replicable proofs of social media identity.
[1] Arguably the hardest problem in PKI: how do you get user to trust that a public key is for the right person? In the classic PGP/GPG web of trust you do things like "key signing parties" and physical in real life interactions and deciding your threshold for how far you trust the friend of my friend signed this key. In the Keybase model you can see that the key (or family of keys) are tied to a certain combo of Twitter, Facebook, HN, et al accounts/profiles and generally trust that the person with all those accounts is the person you are trying to communicate with.
Fair enough, when it comes to coming up with creative ways to solve the web of trust problem.
I still do not know what problem keybase.io solves when they allow uploading of private keys.
That would be the second hardest problem in PKI: key escrow and key management. The answers to the questions most average users have like: What do I do if I lose my machine? If I'm logged in from the library or work or my friend's PC? If I use multiple machines every day?
When the "right" answer includes "Print out this long thing, put it in a safe deposit box, and pray you never have to type in this long string of numbers", you immediately lose a lot of potential users; it doesn't quite fit the "Grandparent test" (could your Grandparent use it?).
Absolutely there's a trade-off in trusting a 3rd Party key escrow, but there's an immense usability benefit to average users that want something easier to do and "some security" really can be better than "no security", even if a lot of hard-line paranoid wonks have good reason to believe otherwise.
My grandparents don't even use email. I don't think we should be setting them as the lowest common denominator for security. Some things that are worth doing require a little bit of effort.
You have have to consider the lowest common denominator in security. You're security it's only as good as your weakest link. Say you have an emergency and your grandparents need to email your PII to a hospital. Can they do it securely? You need to email some PII to them. Can you do it securely? Some security for all is better than no security for most, hence the "grandparent test".
I think it would be even better if we could design systems where it isn't even necessary for a family member to "email your PII" to anyone. That's a terrible idea in almost any situation, regardless of your security.
Yes. Keybase is trying to make a walled garden for itself.
I got really frustrated by this a couple weeks ago when I needed to get a key from a contractor but it was only on Keybase, which at the time I thought could be used as a GPG keyserver.
Edit: I think I found it -- generally referred to as keyservers? Here is a stackexchange post:
http://superuser.com/questions/227991/where-to-upload-pgp-pu...
Can someone please give examples of key-exchange services or server applications? I am getting a bunch of Microsoft exchange results when I try to google it.
The go-to keyserver software is SKS https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home and the network of SKS Keyservers can be found at: https://sks-keyservers.net/
Things to know about keyservers such as SKS: There is no way to remove keys or a way to really delete information. Uploading to know server will propagate that information to all SKS servers in the network over time.
Just because something is useless to you does not mean it's useless to everyone else. There are clearly a lot of people using Keybase.
You don't need to have home brew. And most of this can be done a lot simpler: https://gist.github.com/danieleggert/b029d44d4a54b328c0bac65...
The Homebrew steps seem simpler to me, especially if you already use it. Also easy to update - does the suite auto-update?
Why don't you like Homebrew?
Anybody here got invitation codes for keybase ?
Yep. 28. Email me at [email address redacted].
Send me an email at [my username with the underscore replaced with a period] at the mail service owned by Google.
Hi!
I think I have 20 or so left.
Send a note to hi at myusername [dot] co
You don't need keybase to sign your commits. Any standard and key-exchange compatible pgp/gpg client will do. By using keybase you're just adding more work for everyone.
https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
Keybase makes it really easy to sign commits. By using keybase you get to manage keys and sign quickly. gpg will take hours of reading with its non-intuative cli. You're making less work for yourself.
Gpg is the flossing of encryption. It has great efficacy and terrible efficiency.
I think the cooler part of keybase.io is that it provides a platform for authenticating your separate social accounts (reddit,twitter, etc...) along with websites and github. That's pretty neat, and I can't say I've seen something like it before.
I also have a few. I would be happy to share. myusername at gmail
I've got about 25 left. Feel free to contact me at one of the places listed on my keybase: https://keybase.io/nickpoorman
I have 10 that I'd like to get rid of.
If anyone wants an invitation: username at protonmail.ch.
I have a good number of invites as well. You can email me at [keybase_username] at protonmail.com if you'd like one.
I have a couple dozen. [username] and google's email service. I'm at work now so I might not get to requests until lunch or after work.
I have 22! Contact me via https://keybase.io/csubj
I have a bunch. My keybase is https://keybase.io/dougalsutherland, email is dougal at gmail.
Note that you don't need keybase.io to sign your commits: https://help.github.com/articles/signing-commits-using-gpg/
Thanks for saying this. Or in other words, there are two steps:
1. Make git aware of your signing key
git config user.signingkey "..."
2. Sign the commit
git commit -S ...
That's it.
You can also configure git in global config or per-repo to sign commit automatically:
https://harryrschwartz.com/2014/11/01/automatically-signing-...
...with the added security benefit of not uploading your private key on Keybase!
How is publicly sharing your public key a security flaw?
Keybase would prefer to handle your private key too. You can work with your key offline too, but you have to be aware that this is what you want when setting up- and it's very much not the happy path, so the site will not fully work as you might expect.
Not faulting them, they provide the steps needed, but it might be annoying enough for some people to start uploading private keys.
I've signed up a long time ago (yay early adopters I guess), so I can't comment on the sign up process or setup with your own GPG key nowdays.
But their website works 100% and provides all the functionality if you don't let them host the private key (they give you an easy-to-inspect snippet to paste into your terminal that downloads/signs/uploads things for them. Note, it does do anything when you paste - you need to manually hit enter)
Not disagreeing with you - Just adding my 2c.
It works fine; you just have to know up front to not just click "yes" for everything during the sign-up process. Not a big deal for people who already know how GPG works, but the whole point of Keybase is to make it easier to use for people new to crypto, and that audience can't be expected to understand that the default settings are a terrible idea.
I'm talking about uploading your private key. Obviously, it's required if you want keybase to sign on your behalf.
You can use Keybase with GPG without letting it handle your private key. (I do.)
Same for me.
You can but last time I used it the first option you were presented with was giving keybase your key. I don't know if that's changed years later because I closed the app at that point, I wasn't interested in using or encouraging others to use such a thing. The guy pointing this out was downvoted and I frequently see the fact that its possible to not give them your key presented as somehow making it acceptable that they ask for it.
Which I have opted not to do as a over a decade user of GnuPG. But for complete newbs, JavaScript managed keys is preferable to no key at all.
Much easier than keybase.io. It's still early for keybase though, Im excited to see where they go with it.
I wrote up my own guide a few months ago, when setting up commit signing[0] - keybase optional but encouraged as a nice tool to use.
[0] https://thejacklawson.com/2016/05/gpg/index.html
This is timely, considering Ken's recent hack attempt on his github account.
Does anyone know what happens when commit signatures don't match?
For those out of the loop: http://www.kennethreitz.org/essays/on-cybersecurity-and-bein...
Thanks! That post just prompted me to check what password is on my DNS account, and it turns out to be an insecure one, so I'm fixing that right now.
This setup seems a little simpler (doesn’t require Homebrew, for example): https://gist.github.com/danieleggert/b029d44d4a54b328c0bac65...
Thanks for posting this here.
Please note that this was initially written as a reference for myself, being relatively inexperienced with the keybase client and gpg tooling in general. There are certainly different ways to accomplish the same and you don't have to use keybase, but I wanted to. Please keep this in mind.
Ironically, only the first commit is signed.
Yeah, and even though I had set this up myself just a few minutes before I submitted PR #3, I ended up committing on the web UI as well, with no signature :D
When does keybase plan to do nightly keydumps like SKS offers?
But what do you do with the signatures on the signed commits? It is of some, limited value, to GPG sign because it does provide a little bit more of "John Hancock" for a release, but how does this work in a continuous integration environment? Does the CI server reject commits that are not properly signed? Does the server refuse to run unsigned or incorrectly signed Git deployed code?
It provides a confirmation that the person who's name & email are on a commit actually made the commit. I can configure my instance of git to make commits as "Linus Torvalds <torvalds@linux-foundation.org>", but only the real Linus can sign them with a publicly-verifiable GPG key.
What's the purpose of this? What attack vectors does it expose?
Keybase desires to act as a keyserver and public identity record, keeping your aggregated identity, and a backup of your public and private key pair. The latter is (read: should be) encrypted and only accessible to you. They make that optional, though, and will happily keep track of only your public key. It is absolutely optional, and it exposes you in one critical way: You have to take Keybase's word that they cannot (and will not develop the ability to) access your private key, even though it's on their servers.
I don't use that feature, because I can't see an advantage to it. I can keep a paper copy of my private key in a safety deposit box, if I'm worried about having a secured backup of it that's out of my hands.
You can use it to do actions on the Keybase site by typing in your decryption password. Attack vectors: Keybase site code gets replaced with something malicious, now they have your key password and decrypted private key.
You can also do everything on the command line without trusting Keybase's server or their frontend JS.
Another problem: if their storage or a backup is compromised, the attackers can brute-force passwords offline without rate-limiting.
In some ways that's worse than actively trojaning their JavaScript since there's no possible way for the target to know that's happened whereas the fronted at least has the low but non-zero chance of someone noticing the malicious code.
I'm not sure keybase does this by default, but make sure to upload your key to a keyserver such as MIT's (https://pgp.mit.edu). Otherwise, git will complain that the signature is invalid when doing `git log --show-signature`.
Github doesn't complain for me, so I can only assume that it does this itself. What I did was grab my key from keybase and inserted that into my local keyring, then uploaded that to my github.
GitHub is happy as long as you upload the public key to GitHub. Git though uses pgp key servers to verify the signature.
This is only true if the person looking at the repo doesn't have a copy of your key locally. It's important to remember that all of these tools work offline and don't require some web 2.0 service to operate. :P
If anyone wants in, here are 5 invite links.
[Edit: all used up.]
Each works for only one signup, so hurry up :-)
By the way, most users get around 20 free invites shortly after signing up. If one of the links above opened your account, why not share five of your own invites afterwards?
And should they run dry, here are some more invites:
Edit: 25 people from HN now have a keybase account.
Should anyone care, you can use:
To produce a list of your active invites from the invite page.
I got the second one and just finished setting it up, thanks!
Here are some more –
https://keybase.io/inv/cd1e58f4c6
https://keybase.io/inv/561cd3baeb
https://keybase.io/inv/c794a4ca38
https://keybase.io/inv/5201b55fdd
https://keybase.io/inv/f41ca64909
Here are a couple more:
https://keybase.io/inv/d1439a90ad
https://keybase.io/inv/19ff7aba7d
https://keybase.io/inv/214f008a4f
https://keybase.io/inv/19949fe9a1
https://keybase.io/inv/8c0d7ab033
https://keybase.io/inv/6e0e648a78
https://keybase.io/inv/02bfae461c
https://keybase.io/inv/b643f5505
https://keybase.io/inv/98155df989
https://keybase.io/inv/79f12dd484
https://keybase.io/inv/958a4cd195
https://keybase.io/inv/b030b079ab
https://keybase.io/inv/c931143c09
https://keybase.io/inv/db57114d85
https://keybase.io/inv/5c1a711cdb
https://keybase.io/inv/ffe98c05ab
https://keybase.io/inv/8897ef3a25
https://keybase.io/inv/985f2dcbb6
here's some more:
https://keybase.io/inv/e2d4bf61e4
https://keybase.io/inv/c04b18c7c3
https://keybase.io/inv/e0f10b0fea
https://keybase.io/inv/ab432f0ab7
https://keybase.io/inv/923f343c20
https://keybase.io/inv/27a2dbe5ee
https://keybase.io/inv/6dc9197192
only 1 left of these: https://keybase.io/inv/c04b18c7c3
All gone, sorry folks :)
https://keybase.io/inv/29e91d5669
https://keybase.io/inv/b40111a44d
https://keybase.io/inv/ae995f5329
https://keybase.io/inv/5fa2728e26
https://keybase.io/inv/082c373d2e
https://keybase.io/inv/efab15ecf4
https://keybase.io/inv/3d07ffbb60
https://keybase.io/inv/358d8e5431
https://keybase.io/inv/df136034c9
https://keybase.io/inv/6deb7e80d6
https://keybase.io/inv/0e9ba1298c
https://keybase.io/inv/32f5c89d92
https://keybase.io/inv/7e2a497017
https://keybase.io/inv/d6baeef88d
https://keybase.io/inv/5a11087640
More invites: https://keybase.io/inv/d47ee07f0e https://keybase.io/inv/2abb2ea838 https://keybase.io/inv/a0b686f5f9
Displaying the signature in the web UI is actually the only feature from GitHub I miss when using GitLab. It's not a huge deal, but it gives me a warm-and-fuzzy.
It's on their roadmap: https://gitlab.com/gitlab-org/gitlab-ce/issues/4232
Linus Torvalds, the creator of Git, says that signing every commit is stupid.
http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
And as noted nearly every time this 7-year-old comment by Torvalds is mentioned, this is of course technically correct due to the properties of git's Merkle tree, but completely impractical as far as the human implications.
Consider: You've just written 20 lines of code, and you're creating a commit. Can you validate that all 20 lines were created by you before you commit?
Now, consider that you're looking to create a tag for version 2.0, coming from 1.4, with a net 4,000 new lines of code. Can you quickly and confidently validate that all 4,000 lines of code are as expected?
Clearly, the frequent, small validations are much simpler than infrequently signing huge releases. When integrity matters and humans are involved, small batches win.
If you autosign every commit then you aren't validating anything anyway. All that means is you have another mindless process running automatically in the background. So what's your point?
You're talking about two different threats / attacks:
1. Someone got access allowing them to push commits.
2. Someone got access allowing them to push commits and also got unrestricted access to the trusted PGP key.
In the first case, auto-signing will expose the issue. In the second, not. But in the second case, you're likely screwed in many other ways.
Linus has a point, but it's not without flaws. Linus is saying that it makes you complacent, and doesn't prove anything about any release, and that you should sign golden commits. He says this because only what is shipped needs to be trustworthy; and the value of a signature degrades with the more things it signs.
This raises the question, though; how do you know when you reach that golden commit? Is the signer responsible for auditing every commit since the last signature, every line of code? If he doesn't, what does the signature prove?
That's what Linus has wrong; The signatures aren't about proof, they're about audit trail. For Linus and the kernel.org use case, this isn't necessary. They've already built tooling, and most importantly structure around the code auditing. Every commit that goes into the mainline is somewhat audited by Linus himself. There's a whole layer of competent release engineers in front of him. Code doesn't make it onto the kernel.org repos without having been trusted by a very select group, and doesn't get pulled to master without the word of God.
I suggest, for the average developer, having two keys. One online, to verify that the commit was developed on your computer. One offline, that is only used for releases. One for audit trail, one for golden.
I was also told that having a signature on every commit makes pulling the entire repo take forever (because it has to validate every commit). Not sure how true that is.
While I don't know how bad the performance would be on huge repos, there is of course an option to turn it on or off (--[no-]verify-signatures.) which I believe is off by default.
I have 5 keybase invites free if anyone wants to take them.
Edit: All invites taken
Why would I want to sign all (any?) of my commits? Releases sure, but every single one? What's the point?
Tangentially on topic, when did keybase get that terrible logo? It looks like it'd be the mascot for an off-brand bag of potato chips.
Only signing releases is equivalent to saying "every bit of code I just released I trust and so should you". This means that you have to have reviewed every change to make sure someone didn't dupe you into signing a commit you didn't mean to.
Signing every commit is a much easier guarantee to make: "this change was made by me and I trust this change". In aggregate it's much better than just having signed releases (though of course you should sign releases in addition to this).
Here are some invites if you are interested. (added more, replaced some used ones)
16 used, here are more
Thanks for the invite! I'll reply here with a bunch when mine are available.
Here are a couple I received, a few co-workers took the rest :^)
https://keybase.io/inv/172ce0cd26
https://keybase.io/inv/84129b0e36
and they're gone!
Here are a few as well:
Here's a few more:
https://keybase.io/inv/f36d2463f7
https://keybase.io/inv/902c91e375
https://keybase.io/inv/3f4a976c17
https://keybase.io/inv/39fa8415fc
https://keybase.io/inv/42be11ea6f
https://keybase.io/inv/6dada08bf1
https://keybase.io/inv/c06f6585cb
Here are a few more:
Usage note: "setup" is a noun, "set up" is a verb.
Invites:
https://keybase.io/inv/369352fa18
https://keybase.io/inv/63ab4d212a
I also have a couple of keybase.io invitations:
https://keybase.io/inv/23d5ce3afc
https://keybase.io/inv/bb28df44d6
https://keybase.io/inv/bb9c4fffa8
https://keybase.io/inv/471c1f67b7
https://keybase.io/inv/44968be986
https://keybase.io/inv/cd6c91d01e
https://keybase.io/inv/cdc45eb48f
https://keybase.io/inv/41d268d0d6
https://keybase.io/inv/b74615140f
https://keybase.io/inv/d90ac04ed3
So do I :)
https://keybase.io/inv/8cc6068c31
https://keybase.io/inv/345f0dd4e2
https://keybase.io/inv/2d06418590
https://keybase.io/inv/73fd612897
https://keybase.io/inv/1e9acdc815
https://keybase.io/inv/d5ae0a4b0c
Invites:
https://keybase.io/inv/4c100c57c9
https://keybase.io/inv/89cb21a5a6
More Invites:
https://keybase.io/inv/34fda59c6f
https://keybase.io/inv/27f71dd95c
https://keybase.io/inv/0ba37842db
https://keybase.io/inv/105ba8ef1e
https://keybase.io/inv/070ed67897
https://keybase.io/inv/b5f6094a85
https://keybase.io/inv/5f77883740
https://keybase.io/inv/0cec6fa3d9
Only one left: https://keybase.io/inv/070ed67897
thanks!
Thanks ! :)
I have 22 invites left if anyone would like let me know!
Somebody please explain to me: What's the point in signing on github when I can set the key on github itself (e.g. account gets compromised). A simple flag (on github's server) that is showing that my email on commit is the same as on the account would also do the job. What if my key is compromised and set a new one on github? What happens with my old signed commits? Another question: We are mostly no airplane mechanics which need to sign everything of our work. Why would you give up deniability of doing something (with your signed key) without thinking about the consequences? I'm thinking of legal cases here (hey you signed your commit!).
Github can't verify you actually committed a change unless it's signed. You can set whatever email address you want on any commit.
They could verify who pushed it to github, since that action is authenticated, but restricting pushing other people's commits would break many workflows (eg, a bot pushing from a local git server), or a reviewer pushing code sent to a mailing list, or resolving conflicts in a merge locally.
You can also verify the GPG key independently of Github. Perhaps your CI system could verify all commits it builds are signed, and your deployment system could too. There's no need to use Github as the authoritative source for that sort of thing.
To continue the chain of invites, I have 22 available. You can contact me at matthew at leaguer [dot] io