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.
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.
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.
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.
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.
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?
«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.
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:
I get it. I mostly just meant contributing extra emojis to the issue tracker.
Or if you read the issues you can see that there are some genuine concerns in there that you could help contribute to that would benefit the open source community as a whole, with the side effect of simplifying things for Keybase "as well". Primarily, from skimming, it sounds like the keyserver protocols are not as well documented and standardized as one would assume, running a keyserver from a fresh/new code base is a non-trivial matter with a lot of quirks/bugs to handle. So, who knows, maybe you could contribute to better documenting keyserver quirks, and pushing for better, less quirky, keyserver standards.
> 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.
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.
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.
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
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.
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).
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.
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 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.
