Keybase launches encrypted Git(keybase.io)
keybase.io
Keybase launches encrypted Git
https://keybase.io/blog/encrypted-git-for-everyone
276 comments
So I love Keybase unconditionally and if you guys weren't rolling in physical offices (and not one in Boston) I'd have been beating down your door to come work there--I think what Keybase is doing is important and it's something I'd love to work on. But I have a serious question that maybe you can answer, and it's something everybody who I've showed this to has asked me:
How is Keybase gonna make money? How am I assured that this, and everything else in my Keybase storage, is going to be there in six months? Like, I still have a private server in a closet in my apartment that syncs all the stuff I trust Keybase with because I don't know what the business-side failure case is.
You guys should be taking my money, is what I'm saying. Also probably hiring me. But definitely taking my money.
How is Keybase gonna make money? How am I assured that this, and everything else in my Keybase storage, is going to be there in six months? Like, I still have a private server in a closet in my apartment that syncs all the stuff I trust Keybase with because I don't know what the business-side failure case is.
You guys should be taking my money, is what I'm saying. Also probably hiring me. But definitely taking my money.
We believe the right long-term answer for Keybase is finding a way to charge large corporations and offer pretty much everything else for free. Obviously there would have to be some paid tier if you really wanted 10TB of storage or something, but very few people want that right now. We're still just getting started.
Of course to achieve our goal, we'll also have to find a way to distinguish communities - which we'll want to use Keybase for free - and companies.
Many of us on the team have come from ad-supported businesses and we really, really never want to do that again. I personally guarantee I will never be a "publisher" again. Fortunately that just can't work with Keybase, so no fears there.
But charging for anything on Keybase right now would be a big mistake. We only have ~180,000 users, and we want to bring crypto to everyone. That basically means making products we believe are better.
Another way of looking at your concern: I think if we were charging right now, it wouldn't actually decrease the odds we disappeared in a few years. It might distract our attention from working on the best product and cause our bloody demise. So maybe we're not choosing the path that gives you the highest impression of safety, but I think we actually are.
Of course to achieve our goal, we'll also have to find a way to distinguish communities - which we'll want to use Keybase for free - and companies.
Many of us on the team have come from ad-supported businesses and we really, really never want to do that again. I personally guarantee I will never be a "publisher" again. Fortunately that just can't work with Keybase, so no fears there.
But charging for anything on Keybase right now would be a big mistake. We only have ~180,000 users, and we want to bring crypto to everyone. That basically means making products we believe are better.
Another way of looking at your concern: I think if we were charging right now, it wouldn't actually decrease the odds we disappeared in a few years. It might distract our attention from working on the best product and cause our bloody demise. So maybe we're not choosing the path that gives you the highest impression of safety, but I think we actually are.
Everything you just said makes perfect sense.
That being said, I think Keybase is one of the most important companies around right now. I would gladly pay $10/month, even if literally all it did was put a "Supporter" badge on my profile. I'm sure hundreds of other people agree.
Crypto is far too important for it to remain locked away behind GPG.
That being said, I think Keybase is one of the most important companies around right now. I would gladly pay $10/month, even if literally all it did was put a "Supporter" badge on my profile. I'm sure hundreds of other people agree.
Crypto is far too important for it to remain locked away behind GPG.
The outpouring of positive energy (on HN!) is really inspiring. Everyone on the Keybase team is feeling good about our work right now, so thanks!
The team seriously deserves it.
For what it's worth, I think my above comment is my highest upvoted comment of all time. There's a lot of people out there who want Keybase to succeed.
For what it's worth, I think my above comment is my highest upvoted comment of all time. There's a lot of people out there who want Keybase to succeed.
My comment that started this subthread is in my top ten, and I have been here entirely too long, so, yeah. Keybase is good. It staying around is important. People around here, at least, seem to know it, and that's awesome.
Get off HN and take my money already. Seriously. I'd gladly pay you money for nothing, a "supporter" badge would only be a nice bonus
I too would pay for a "supporter badge".
I would happily pay $10/month just to support the business. I don’t even need extra features. Please ask me for money.
Piggybacking off of the original question, I too have a question in this scope:
With all the products you're offering, is there any indication which products will be staples of Keybase? Eg, I'm always hesitant of the "Google Product", where something gets added only to be abandoned ~1yr later after it doesn't gain the traction the company expected.
For example, I'd love to get my wife and I switched to Keybase Chat from Telegram. With that said, I love the features of Telegram, they're killing it for me honestly, but I can't expect Keybase to compete with Telegram unless they're really invested in it.
So which products from Keybase are one-off experiments, and which are long-roadmapped products - expected to have continued development and support for years to come? I'm having trouble understanding what to trust.
Note, none of this is critical to Keybase. I'm wary of startups in general, despite loving you guys, so I'm just seeking understanding. I appreciate whatever information you can give me, even if small :)
With all the products you're offering, is there any indication which products will be staples of Keybase? Eg, I'm always hesitant of the "Google Product", where something gets added only to be abandoned ~1yr later after it doesn't gain the traction the company expected.
For example, I'd love to get my wife and I switched to Keybase Chat from Telegram. With that said, I love the features of Telegram, they're killing it for me honestly, but I can't expect Keybase to compete with Telegram unless they're really invested in it.
So which products from Keybase are one-off experiments, and which are long-roadmapped products - expected to have continued development and support for years to come? I'm having trouble understanding what to trust.
Note, none of this is critical to Keybase. I'm wary of startups in general, despite loving you guys, so I'm just seeking understanding. I appreciate whatever information you can give me, even if small :)
Why not use signal?
My best guess as an uninformed lurker and a Keybase user is that it's too early to know. You would have to know what's the impact of "sunsetting" features and for that you probably need more than 180k early adopters.
In case of chat you can always fallback to Telegram (I've done that after trying to move people to Wire).
In case of git you can always move the repo.
With the setup that's there now I can see how it could be used as the main origin along with a push to GitHub hook. Pull requests would be even mergable (blessed be Torvalds), though I'm not 100% sure if GitHub would pick up on that and autoclose the PR.
In case of chat you can always fallback to Telegram (I've done that after trying to move people to Wire).
In case of git you can always move the repo.
With the setup that's there now I can see how it could be used as the main origin along with a push to GitHub hook. Pull requests would be even mergable (blessed be Torvalds), though I'm not 100% sure if GitHub would pick up on that and autoclose the PR.
The enterprise would be a valid target, but if you really want them to trust you, you'll need to offer localized hosting (host from EU, Russian, Chinese datacenters) as well as on-premise hosting.
Actually, in that last one you should probably also offer consultancy to set up the servers securely - both software and physical hardware security. Secure software isn't worth much if the systems it runs on is compromised. Consultancy can be worth a lot of money, if your customers think it's worth it.
I'd start working on offering a paid enterprise solution soon tbf. I'd also tweak your landing page, the blurb is "a new and free security app"; the "new and free" doesn't instill much trust, and the "security app" doesn't really describe what it does. The second phrase tries to explain that "it's Slack" or "it's Dropbox", which I guess is fair, but I'd aim towards distancing yourself and describe it as e.g. "End-to-end encrypted communications and file sharing". What makes Keybase unique? I mean Dropbox has a pretty solid security page (https://www.dropbox.com/business/trust/security/architecture), as does Slack (https://slack.com/security).
Actually, in that last one you should probably also offer consultancy to set up the servers securely - both software and physical hardware security. Secure software isn't worth much if the systems it runs on is compromised. Consultancy can be worth a lot of money, if your customers think it's worth it.
I'd start working on offering a paid enterprise solution soon tbf. I'd also tweak your landing page, the blurb is "a new and free security app"; the "new and free" doesn't instill much trust, and the "security app" doesn't really describe what it does. The second phrase tries to explain that "it's Slack" or "it's Dropbox", which I guess is fair, but I'd aim towards distancing yourself and describe it as e.g. "End-to-end encrypted communications and file sharing". What makes Keybase unique? I mean Dropbox has a pretty solid security page (https://www.dropbox.com/business/trust/security/architecture), as does Slack (https://slack.com/security).
> localized hosting
IIRC it boils down to a new Merkle root and a self-hosted server instance that uses it. Add snapshot pushing to the blockchain and you've got yourself an independent Keybase instance with a fresh and clean database ready to be filled with employees.
I wonder what the identity proof adding would look like. I guess corporations are not interested in public proofs from Twitter.
IIRC it boils down to a new Merkle root and a self-hosted server instance that uses it. Add snapshot pushing to the blockchain and you've got yourself an independent Keybase instance with a fresh and clean database ready to be filled with employees.
I wonder what the identity proof adding would look like. I guess corporations are not interested in public proofs from Twitter.
If you're going to host locally doesn't it matter much less that it's encrypted? You could just use github enterprise.
I'm (unfortunately, at times) intimately familiar with what big corporate IT departments look for in terms of features, authentication, RBAC, auditing, etc., etc. in "Enterprise" products and if you need it I'd be willing to help you understand what we look for and why. Feel free to drop me a line. Either way, I love what you're doing and I hope you nail it.
Not affiliated with Keybase, but I’d love to get your perspective on those things. I don’t see a way to contact you in your HN bio. Send me a note? https://alanhogan.com/contact?reason=corporate%20IT%20dept%2...
(Anyone else with relevant thoughts on what IT needs around encryption, recovery, key backup, etc, please feel free to write me, too)
(Anyone else with relevant thoughts on what IT needs around encryption, recovery, key backup, etc, please feel free to write me, too)
OK, awesome. I'm glad you wrote this, because this makes me feel a heck of a lot better about using Keybase. This was in a way my hunch, but I figured--this is something good and cool, I want to make sure it stays good and cool. =) Thanks for the reply.
This is a fantastic answer, and I wish more folks were this dedicated to making sure they have something great before trying to hawk it. That said, I do wish I could pay for (at least) a TB of Keybase storage right now. :D
David Heinemeier Hansson and the Basecamp guys would disagree :)
I think Keybase is more like what Joel Spolsky describes as a "horizontal company" that's appropriate to try to build after already having made money. https://www.joelonsoftware.com/2012/01/06/how-trello-is-diff...
From Joel's article:
> That means that our highest priority is removing any obstacles to adoption. Anything that people might use as a reason not to use Trello has to be found and eliminated.
In this case I am weary of using something like this that is free because I have seen so many things in the past that were free only to shutdown rapidly after they grew in size, but with no way to pay for themselves and had to pivot or sell out. So being free is actually an obstacle in adoption.
> That means that our highest priority is removing any obstacles to adoption. Anything that people might use as a reason not to use Trello has to be found and eliminated.
In this case I am weary of using something like this that is free because I have seen so many things in the past that were free only to shutdown rapidly after they grew in size, but with no way to pay for themselves and had to pivot or sell out. So being free is actually an obstacle in adoption.
I am intimately aware of this frustration, but what's the alternative? Stable companies also kill or abandon projects. The whole software and consumer product ecosystems are constantly churning.
Personally I'm old enough that I don't have to try every new service, but if something is solving a real problem in the short-term, I will give it a try and hope for the best. Keybase is definitely in this bucket. Worst case they go away and I have to come up with a different solution, but right now it's adding tremendous value.
Personally I'm old enough that I don't have to try every new service, but if something is solving a real problem in the short-term, I will give it a try and hope for the best. Keybase is definitely in this bucket. Worst case they go away and I have to come up with a different solution, but right now it's adding tremendous value.
but what's the alternative? Stable companies also kill
or abandon projects.
Nobody shuts down a project that costs $500,000 per annum and brings in $1,000,000 per annum.
Of course, 'all costs' there doesn't just mean employee salary - it has to include difficult-to-measure costs like the opportunity costs of the attention it demands from executives, paying a portion of the support costs of any legacy systems it needs, and suchlike.
Fortunately, Trello's free plan limits are so low that very little of substance will be lost.
Throwing my "I <3 Keybase" comment in the ring while doing some brainstorming here.
It seems to me that there's a lot of product opportunities in the corporate world that go beyond what Keybase is providing today. Chat and Git are interesting, but there's already a lot of momentum in both these areas. Been thinking how I use encryption and where things fall short today. One of those areas is build signing and hardware key management for our team.
Everything that goes on our servers get signed by an official PGP key. Only a couple people can sign builds, and each has a Yubikey with PGP subkeys on it. This is kind of annoying to manage. We use an airgapped computer that houses the private key, can create subkeys and assign to Yubikeys, can handle expiration management, etc. When we want to deal with this, we have to get the computer, unlock access, and deal with the command line. This is error-prone and annoying. Having a solution that allows for safe storage of a private key and easy management of subkeys on smartcards would be amazing without the need for an airgapped computer and a command line would be really interesting.
(The signing/verification part can probably be handled today by the keybase tool.)
Okay, that's maybe more specialized. Let's move away from paranoid server builds and go toward something similar that's gotten plenty of companies in trouble: Malicious e-mails. How often are we hearing about some poor employee receiving an e-mail that appears to come from a co-worker that contains a finance document with a trojan? Or maybe just a simple document with a form, instructions, and a link that results in information leaked to some third-party?
If there was a dead-simple way to sign and validate documents over Keybase (and I mean dead-simple, built for people who only know Word and Excel), for use in e-mail and document management, with marketing around "For $XX/user/month, you don't have to worry about getting hacked," I bet plenty of companies would bite.
I don't know what that looks like exactly, but just playing around loosely with some thoughts, it would be interesting (particularly for fully IT-managed systems) to have a Keybase Shield product that would automate much of the signing and verification of documents. It could tie into Word, Excel, etc. via their plugin interface and sign on save, and/or provide a big "Sign this document" widget on the side of the screen that a document can be dropped onto (or a Share action on phones). It'd then own the file associations for these documents, intercepting them when opening via e-mail or file servers, and would validate their signature. A document from the outside world (or one not going through the corporate-mandated signature process) would outright fail to open with an error message and instructions to ask the sender to please sign the document.
(Lots of details to work out there, but if this process could be made simple and mostly automatic, you'd help close a major attack vector that companies are susceptible to today.)
Anyway, it's great hearing your thoughts on how Keybase plans to make money. I've been in the same boat of loving Keybase but being uncertain about where it'll be 5 years from now. We'll keep an eye open for some paid products :)
It seems to me that there's a lot of product opportunities in the corporate world that go beyond what Keybase is providing today. Chat and Git are interesting, but there's already a lot of momentum in both these areas. Been thinking how I use encryption and where things fall short today. One of those areas is build signing and hardware key management for our team.
Everything that goes on our servers get signed by an official PGP key. Only a couple people can sign builds, and each has a Yubikey with PGP subkeys on it. This is kind of annoying to manage. We use an airgapped computer that houses the private key, can create subkeys and assign to Yubikeys, can handle expiration management, etc. When we want to deal with this, we have to get the computer, unlock access, and deal with the command line. This is error-prone and annoying. Having a solution that allows for safe storage of a private key and easy management of subkeys on smartcards would be amazing without the need for an airgapped computer and a command line would be really interesting.
(The signing/verification part can probably be handled today by the keybase tool.)
Okay, that's maybe more specialized. Let's move away from paranoid server builds and go toward something similar that's gotten plenty of companies in trouble: Malicious e-mails. How often are we hearing about some poor employee receiving an e-mail that appears to come from a co-worker that contains a finance document with a trojan? Or maybe just a simple document with a form, instructions, and a link that results in information leaked to some third-party?
If there was a dead-simple way to sign and validate documents over Keybase (and I mean dead-simple, built for people who only know Word and Excel), for use in e-mail and document management, with marketing around "For $XX/user/month, you don't have to worry about getting hacked," I bet plenty of companies would bite.
I don't know what that looks like exactly, but just playing around loosely with some thoughts, it would be interesting (particularly for fully IT-managed systems) to have a Keybase Shield product that would automate much of the signing and verification of documents. It could tie into Word, Excel, etc. via their plugin interface and sign on save, and/or provide a big "Sign this document" widget on the side of the screen that a document can be dropped onto (or a Share action on phones). It'd then own the file associations for these documents, intercepting them when opening via e-mail or file servers, and would validate their signature. A document from the outside world (or one not going through the corporate-mandated signature process) would outright fail to open with an error message and instructions to ask the sender to please sign the document.
(Lots of details to work out there, but if this process could be made simple and mostly automatic, you'd help close a major attack vector that companies are susceptible to today.)
Anyway, it's great hearing your thoughts on how Keybase plans to make money. I've been in the same boat of loving Keybase but being uncertain about where it'll be 5 years from now. We'll keep an eye open for some paid products :)
On the document management end of things: that's exactly what the public/yourname/ subdirectory of KBFS is-- every document there gets signed when edited, then they're automatically verified (by the KBFS client) when someone tries to download them (either the original author, or another Keybase user).
There's no explicit signing process involved, but that's part of Keybase's value proposition: automatic and transparent public key cryptography.
There's no explicit signing process involved, but that's part of Keybase's value proposition: automatic and transparent public key cryptography.
If you can tie the shield into KBFS, that's even better. It's not enough to protect a company from attacks, though. People may still click that random document coming in via e-mail that claims to be from a co-worker. A mandatory technical solution on that end, no matter what the actual technology looks like under the hood, would be essential for protecting people from making these kinds of mistakes.
The value proposition of automatic and transparent public key cryptography is strong, and what I love about Keybase. Just thinking of other ways that can be applied transparently.
The value proposition of automatic and transparent public key cryptography is strong, and what I love about Keybase. Just thinking of other ways that can be applied transparently.
A team-based 1Password-type service would also be interesting, particularly one allowing heavy use of 2-factor authentication with something like a Yubikey.
What you said is music to my ears... I share concern. I love you guys and thank you for amazing work you did so far.
Thank you, thank you, thank you.
Thank you, thank you, thank you.
> Many of us on the team have come from ad-supported businesses and we really, really never want to do that again. I personally guarantee I will never be a "publisher" again.
So prove it. Provide a way that customers can try to give you money for solving their problems. Even if it is just a dummy static page with a form to contact your "sales" department, really show that you will be here for the longer term.
So prove it. Provide a way that customers can try to give you money for solving their problems. Even if it is just a dummy static page with a form to contact your "sales" department, really show that you will be here for the longer term.
Putting up a fake sales page isn't a sales strategy and wouldn't prove anything. If anything, it could add to the distraction.
Sales and being around long term are more complicated and won't simply be proven to you because it's what you want. It requires more vision and coherence than that.
Sales and being around long term are more complicated and won't simply be proven to you because it's what you want. It requires more vision and coherence than that.
It doesn't have to be a fake page, talking about a mvp where they can gauge who is interested in paying and what their problems are so they can concentrate in those areas. When confident they could even setup a simple paypal re-occuring sale system too.
A better(maybe?) idea could be to send out a survey asking what features people are interested in, whether they would be willing to pay for them, and how much if so.
It could be an option when you log in to the UI. I wouldn't mind it, as long as it isn't being e-mailed to me every week/month.
It could be an option when you log in to the UI. I wouldn't mind it, as long as it isn't being e-mailed to me every week/month.
> You guys should be taking my money, is what I'm saying.
Completely agreed. The reason I don't use Keybase more than I do is because I half expect them to be acquired/something else to happen. Would gladly give them my $10/mo. for a 1TB instead of Dropbox.
With that said, I completely understand why they aren't right now -- maybe they're not going after the consumer market, maybe they don't want to box themselves in with customer support obligations, etc. But I really would like to use them.
Completely agreed. The reason I don't use Keybase more than I do is because I half expect them to be acquired/something else to happen. Would gladly give them my $10/mo. for a 1TB instead of Dropbox.
With that said, I completely understand why they aren't right now -- maybe they're not going after the consumer market, maybe they don't want to box themselves in with customer support obligations, etc. But I really would like to use them.
For sure. I would give them my ten bucks a month for the 100GB I get for free.
@malgorithm's answer is fantastic, just wanted to add some side-comments...
> How am I assured [?]
You're not, even if they start making money. Sucks, but true.
> You guys should be taking my money
One way to pay, if you want to help ensure their success & longevity, is to evangelize for them, and get other people hooked on their product. Getting other people hooked on it like you are and seeing the potential and get over the adoption humps... that's valuable! They're not taking money because it raises the barrier to entry, and growth is most important. Pay them by helping them grow.
> How am I assured [?]
You're not, even if they start making money. Sucks, but true.
> You guys should be taking my money
One way to pay, if you want to help ensure their success & longevity, is to evangelize for them, and get other people hooked on their product. Getting other people hooked on it like you are and seeing the potential and get over the adoption humps... that's valuable! They're not taking money because it raises the barrier to entry, and growth is most important. Pay them by helping them grow.
It's valuable, but not in the capital sense. Each person you get hooked on their product increases their burn rate, and both makes them more attractive as an acquisition (which is scary for users) and more desperate for cash (which makes acquiescing to acquisition more tempting).
Without a road to profitability (or at least a road to revenue) even attracting equity is difficult; investors who enter with that knowledge will be looking to exit through acquisition, since that's basically the only way to exit, other than just getting more capital.
Without a road to profitability (or at least a road to revenue) even attracting equity is difficult; investors who enter with that knowledge will be looking to exit through acquisition, since that's basically the only way to exit, other than just getting more capital.
100% agreed. Hosting sensitive git repositories is problem that companies and people are willing to pay $$$ for and stuff that is free has a tendency to go away after a few years. Heck don't bother putting any technical work into it or anything (aka work) and continue being free, but allow me to have a "paying account" or whatever. Pretty much if you are providing value let me prove it by giving you some cash.
> Keybase team member here. Interesting fact: git doesn't check the validity of sha-1 hashes in your commit history.
I heard this a couple of times and tried to confirm it a while ago, but was unable to. I wasn't able to forge a repository with faulty hashes in it. I also heard plenty of people tell me that there exist public repositories with wrong hashes in them, but when I asked them they never could come up with concrete examples in the wild.
I'm seriously curious about this, can you provide any clonable proof of concept repository with wrong hashes?
I heard this a couple of times and tried to confirm it a while ago, but was unable to. I wasn't able to forge a repository with faulty hashes in it. I also heard plenty of people tell me that there exist public repositories with wrong hashes in them, but when I asked them they never could come up with concrete examples in the wild.
I'm seriously curious about this, can you provide any clonable proof of concept repository with wrong hashes?
> git doesn't check the validity of sha-1 hashes in your commit history. Meaning if someone compromises your hosted origin, they can quietly compromise your history.
That second part of the fuller quote makes the first part irrelevant.
Git, sans GPG, does no validation of the given username and email - it is trivial to configure my laptop to stamp commits with hannob@ instead fragmede. All I need to do to frame hannob, then, is write access to a repo that they contribute to.
In the centralized world of github, that's a little bit more tricky, but at larger organizations where large groups (eg, all of eng) simply have write access to the repo(s), if git blame says hannob wrote the commit that stole passwords/money/etc, guess who's getting fired?
With GPG, I'm able to configure git so that commits that actually come from me have a GPG-validated signature. Snarkily, the blog post claims "no one" does this but I do. Given that this feature is known to be infrequently used, I'd believe it if git would accept commits with a bad signature.
That second part of the fuller quote makes the first part irrelevant.
Git, sans GPG, does no validation of the given username and email - it is trivial to configure my laptop to stamp commits with hannob@ instead fragmede. All I need to do to frame hannob, then, is write access to a repo that they contribute to.
In the centralized world of github, that's a little bit more tricky, but at larger organizations where large groups (eg, all of eng) simply have write access to the repo(s), if git blame says hannob wrote the commit that stole passwords/money/etc, guess who's getting fired?
With GPG, I'm able to configure git so that commits that actually come from me have a GPG-validated signature. Snarkily, the blog post claims "no one" does this but I do. Given that this feature is known to be infrequently used, I'd believe it if git would accept commits with a bad signature.
Likewise, I would be keen to see an example of this.
I may be wrong, but here's my current understanding.
I believe Git CAN check the validity of sha1 hashes (I read the source a few years ago and have a very tiny git commit) using git fsck, which I believe kernel.org does nightly. It just doesn't do so automatically with every commit or whatever. But you can set up a test in your server, I believe, if that's important to you, either watching the files, or checking pushes which I believe github does. So that's not the issue.
It's sha-1 collision attacks that are a theoretical issue.
My understanding of the currently known SHA-1 attack is that it requires binary data (hence PDF files for the example) and requires you to control both the original file and the subsequent file. So an attack would have to generate an apparently innocent file and a malicious file both of which have a binary block, insert the innocent file into the repo, and then somehow, most likely outside of a git push given mitigations like github's, replace that innocent file with the malicious file.
Now to your question, checking in the PDF files from the proof of the attack in git doesn't work, because git also adds header info. And generating the files requires ~ $100,000 dollars worth of ec2 time, or the equivalent, so nobody has gone through the trouble of generating files that allow this specifically to prove it for git. Bit it's definitely possible, and cheap enough for a criminal organization or a state agency to do. Just because someone hasn't done it for git specifically shouldn't mean that the attack isn't possible, just that security researchers don't have unlimited funds, and the existing proof, while not specific to git shows the issue generally applies.
Last I saw, the git mailing list was debating sha3-256 and BLAKE vs SHA-256. There's some indication that SHA-256 may get intel HW support, and that may be useful for speed with really really big git repos (like microsoft's apparently). SHA-256 doesn't have an attack on it that's known but unlike ShA3-256 (and I believe BLAKE since it's a stream cipher) SHA-256 is a block cipher, so it's not stateful. That means, while no known attack exists, theoretically if an attack existed you could corrupt a specific block in a similar manner to SHA-1. But SHA-256 has been much more extensively tested for issues while SHA3-256 is newer... it was created ostensibly as a backup in case the current known safe standard of crypto like SHA-256 is attackable.
There are some issues with SHA-256 being used in repos that have signed SHA-1 hashes already, in terms of mapping SHA-256 to SHA-1 hashes without borking the signing. Obviously if you change the underlying structure of signed stuff to store a new hash, it changes the hash.
My personal thought would be to implement SHA-256 and SHA3-256 as options simultaneously, as they are both NIST standards, make SHA-256 the standard so big repos can be as fast as possible.
I am not a crypto expert, or a git expert though, so if I'm wrong, please correct me. Being wrong means I get to learn stuff and that's great!
I believe Git CAN check the validity of sha1 hashes (I read the source a few years ago and have a very tiny git commit) using git fsck, which I believe kernel.org does nightly. It just doesn't do so automatically with every commit or whatever. But you can set up a test in your server, I believe, if that's important to you, either watching the files, or checking pushes which I believe github does. So that's not the issue.
It's sha-1 collision attacks that are a theoretical issue.
My understanding of the currently known SHA-1 attack is that it requires binary data (hence PDF files for the example) and requires you to control both the original file and the subsequent file. So an attack would have to generate an apparently innocent file and a malicious file both of which have a binary block, insert the innocent file into the repo, and then somehow, most likely outside of a git push given mitigations like github's, replace that innocent file with the malicious file.
Now to your question, checking in the PDF files from the proof of the attack in git doesn't work, because git also adds header info. And generating the files requires ~ $100,000 dollars worth of ec2 time, or the equivalent, so nobody has gone through the trouble of generating files that allow this specifically to prove it for git. Bit it's definitely possible, and cheap enough for a criminal organization or a state agency to do. Just because someone hasn't done it for git specifically shouldn't mean that the attack isn't possible, just that security researchers don't have unlimited funds, and the existing proof, while not specific to git shows the issue generally applies.
Last I saw, the git mailing list was debating sha3-256 and BLAKE vs SHA-256. There's some indication that SHA-256 may get intel HW support, and that may be useful for speed with really really big git repos (like microsoft's apparently). SHA-256 doesn't have an attack on it that's known but unlike ShA3-256 (and I believe BLAKE since it's a stream cipher) SHA-256 is a block cipher, so it's not stateful. That means, while no known attack exists, theoretically if an attack existed you could corrupt a specific block in a similar manner to SHA-1. But SHA-256 has been much more extensively tested for issues while SHA3-256 is newer... it was created ostensibly as a backup in case the current known safe standard of crypto like SHA-256 is attackable.
There are some issues with SHA-256 being used in repos that have signed SHA-1 hashes already, in terms of mapping SHA-256 to SHA-1 hashes without borking the signing. Obviously if you change the underlying structure of signed stuff to store a new hash, it changes the hash.
My personal thought would be to implement SHA-256 and SHA3-256 as options simultaneously, as they are both NIST standards, make SHA-256 the standard so big repos can be as fast as possible.
I am not a crypto expert, or a git expert though, so if I'm wrong, please correct me. Being wrong means I get to learn stuff and that's great!
SHA2-256 has had hardware acceleration instructions on Intel since the Skylake series and on AMD since Ryzen; even ARM has has SHA2-256 acceleration for a while. Software support is the issue at this point.
How likely/easy would it be to add "know nothing" mirrors of these encrypted repositories? Say that I trust the keybase app (or something that speaks its protocols) possibly indefinitely, but maybe I'm not keen on a single cloud storage backend and want additional secure backup options. (Maybe I'm even unconvinced about the long term guarantee of keybase's storage space offerings due to possibly changing cost/business model factors, as others have pointed out here.)
It would be nice if I could have an encrypted copy in S3 or Dropbox or somewhere, that presumably maybe git couldn't directly make use of, and would be encrypted and those services couldn't touch either, but that the app could still push/pull changes to.
Certainly, I'd still have an unencrypted view of the contents in any local clones of the repository I may have in the case that I couldn't access keybase storage, but it still seems like there may be useful cases where an encrypted backup is somewhere else in the cloud as well, as a safe failover just in case.
It would be nice if I could have an encrypted copy in S3 or Dropbox or somewhere, that presumably maybe git couldn't directly make use of, and would be encrypted and those services couldn't touch either, but that the app could still push/pull changes to.
Certainly, I'd still have an unencrypted view of the contents in any local clones of the repository I may have in the case that I couldn't access keybase storage, but it still seems like there may be useful cases where an encrypted backup is somewhere else in the cloud as well, as a safe failover just in case.
You can do this with a Git helper like this one:
- [spwhitton/git-remote-gcrypt: PGP-encrypted git remotes](https://github.com/spwhitton/git-remote-gcrypt)
I use [Pass](https://www.passwordstore.org/), a password manager, which uses GPG and Git, and I keep an encrypted copy of my Pass Git repo in Dropbox and have that repo copy setup as a remote in all of the local copies of my password repo. So, the contents of the local repos are encrypted, but in the encrypted copy all of the Git data is encrypted too.
- [spwhitton/git-remote-gcrypt: PGP-encrypted git remotes](https://github.com/spwhitton/git-remote-gcrypt)
I use [Pass](https://www.passwordstore.org/), a password manager, which uses GPG and Git, and I keep an encrypted copy of my Pass Git repo in Dropbox and have that repo copy setup as a remote in all of the local copies of my password repo. So, the contents of the local repos are encrypted, but in the encrypted copy all of the Git data is encrypted too.
> git doesn't check the validity of sha-1 hashes in your commit history.
By default. But set "git config --global transfer.fsckObjects true" and it will. No need to install anything else just for that.
By default. But set "git config --global transfer.fsckObjects true" and it will. No need to install anything else just for that.
Who actually does that though? I'm guessing less than 1% of users. Any idea why it isn't on by default?
While talking about git and security:
Signing tags are not as affective as you'd think. refs are never actually signed, it's the objects they are pointing at that are signed. This opens up to interesting attacks where you can move refs around to previous vulnerable versions.
Git also never checks if the metadata the tag points at is correct!
Interesting paper: https://www.usenix.org/system/files/conference/usenixsecurit...
Signing tags are not as affective as you'd think. refs are never actually signed, it's the objects they are pointing at that are signed. This opens up to interesting attacks where you can move refs around to previous vulnerable versions.
Git also never checks if the metadata the tag points at is correct!
Interesting paper: https://www.usenix.org/system/files/conference/usenixsecurit...
Yeah, we implemented this paper's proposal (their version has some bugs, gaps, and infinite loop issues) where I work to be able to have higher assurance on the validity of our source repositories.
First version in shell with a fairly robust test suite, and the next version in Rust. Originally started to do it in Rust, but libgit2 was sufficiently obtuse that we opted for getting to a complete, working thing first.
First version in shell with a fairly robust test suite, and the next version in Rust. Originally started to do it in Rust, but libgit2 was sufficiently obtuse that we opted for getting to a complete, working thing first.
This looks fantastic! I have a couple of questions not answered in the FAQ though:
1. Is there (or will there be) any way to create an encrypted git repo shared between a few users that aren't part of a team? e.g. could I create a repo that belongs to eridius,chris and have us both access it?
2. Can I create a repo that belongs to a subteam?
And on a different note, I want to create a team but the name is currently taken by a user. The user has zero activity (no devices, no proofs, chain is completely empty, literally nothing). Is there any way to recover a name that's being squatted on?
1. Is there (or will there be) any way to create an encrypted git repo shared between a few users that aren't part of a team? e.g. could I create a repo that belongs to eridius,chris and have us both access it?
2. Can I create a repo that belongs to a subteam?
And on a different note, I want to create a team but the name is currently taken by a user. The user has zero activity (no devices, no proofs, chain is completely empty, literally nothing). Is there any way to recover a name that's being squatted on?
> 1. Is there (or will there be) any way to create an encrypted git repo shared between a few users that aren't part of a team? e.g. could I create a repo that belongs to eridius,chris and have us both access it?
Yep, though it's undocumented and it won't show up in the GUI right now (maybe ever). You can just push/pull directly to repos like "keybase://private/u1,u2,u3/foo" and it will create it on the fly. But we warned, there's currently no way to delete those, and typos in the git URL can cause unintended repos to pop up.
> Can I create a repo that belongs to a subteam?
Yep, should be the same as a regular team.
Yep, though it's undocumented and it won't show up in the GUI right now (maybe ever). You can just push/pull directly to repos like "keybase://private/u1,u2,u3/foo" and it will create it on the fly. But we warned, there's currently no way to delete those, and typos in the git URL can cause unintended repos to pop up.
> Can I create a repo that belongs to a subteam?
Yep, should be the same as a regular team.
I will pay a LOT of money if you can slap a half decent web interface on it.
Surprisingly, you guys look like a direct clone of the new Bitbucket interface. Its not my favorite (I like github so much better) - but Bitbucket with its inbuilt Pipelines integrations is so much better than Github.
Surprisingly, you guys look like a direct clone of the new Bitbucket interface. Its not my favorite (I like github so much better) - but Bitbucket with its inbuilt Pipelines integrations is so much better than Github.
But how will their web server present that data? They can't read the data.
> Interesting fact: git doesn't check the validity of sha-1 hashes in your commit history.
Isn't the commit sha1 determined, in part, by the sha1 values of the tree it refers to as well as the sha1 of the parent commit? If you fetch a branch from a compromised remote, all the sha1 values of the commits that were compromised would be different.
Isn't the commit sha1 determined, in part, by the sha1 values of the tree it refers to as well as the sha1 of the parent commit? If you fetch a branch from a compromised remote, all the sha1 values of the commits that were compromised would be different.
Correct, but git doesn't recompute the hashes locally, so it wouldn't know they are wrong.
Ah, so if I were to manually craft a commit in a text editor in the format:
That is, would it think it has the commit because the sha1 hasn't changed, but the tree sha1 has been updated and it would presumably refer to blobs that the client doesn't already have and try to fetch them. Or would it not proceed because it already has the commit?
tree sha1
parent sha1 of parent I want to attach it to
author some string
committer some string
The commit message
That is, would it think it has the commit because the sha1 hasn't changed, but the tree sha1 has been updated and it would presumably refer to blobs that the client doesn't already have and try to fetch them. Or would it not proceed because it already has the commit?
It doesn't seem to verify hashes of objects on checkout, but it does when receiving packfiles. So it's difficult to see how this could be an exploit unless the attacker has access to your local .git directory.
If you're syncing the repository itself (e.g. over Dropbox) instead of using git remotes, then it could be exploited.
Why the hell would you do that. That defeats the point of git.
Because anything that can be misused will be.
I’m sure there’s a law with someone’s name that states that. But just in case it hasn’t been claimed yet, I’m proposing that we call it the fuck you law. Because the next time someone comes to me to ask me to fix their trello to zappier to email to google sheets setup they use as a project management tool, I want to be able to say, “Fuck you and there’s a law that says so.”
I’m sure there’s a law with someone’s name that states that. But just in case it hasn’t been claimed yet, I’m proposing that we call it the fuck you law. Because the next time someone comes to me to ask me to fix their trello to zappier to email to google sheets setup they use as a project management tool, I want to be able to say, “Fuck you and there’s a law that says so.”
No it doesn't. I have many of my git repos in Dropbox but I'm not using Dropbox for sharing. Having those in Dropbox means I get automatic backup and that they are available when I switch to a different computer, which I do, but not frequently. As only I use my Dropbox account, I'm aware of the potential sync problem, but it's never been a problem. I do run fsck & gc more frequently than most, but I probably don't need to.
EDIT: I should emphasize that this model is way more convenient than manually having to remember to push and pull all the time. Now push is only for publishing outside as it should be.
EDIT: I should emphasize that this model is way more convenient than manually having to remember to push and pull all the time. Now push is only for publishing outside as it should be.
If you're doing this then there's no reason to use git. Just sync a raw directory.
No, I use git to track my development history and I push to github. These are two difference issues.
[deleted]
For your first point, can't you verify the signature for the commit? In order to to compromise the origin, they must also compromise the secret key of whoever is signing commits.
I say that in full realization that 99% of people probably don't even know that you can sign commits, but the first point doesn't seem valid, as you can ensure integrity of commit history.
I say that in full realization that 99% of people probably don't even know that you can sign commits, but the first point doesn't seem valid, as you can ensure integrity of commit history.
And even then, I never could break over the hurdle of setting up team repositories with safe credential management...like for any kind of collaboration. With this simple screen, you can grab 5 friends, make a repo in a minute, and all start working on it.
You can already do that with Gogs.. It's a single binary, uses git, supports accounts, 2 factor, etc. https://gogs.io/ Really useful for small teams that don't want to use github or gitlab.
You can already do that with Gogs.. It's a single binary, uses git, supports accounts, 2 factor, etc. https://gogs.io/ Really useful for small teams that don't want to use github or gitlab.
Congratulations on the launch. I'm a Keybase user myself and I think you all have done a fantastic job.
When the SHA-1 collision was calculated earlier this year, Linus commented on git and SHA-1. No further questions, just sharing it here if you happened not to see it: https://marc.info/?l=git&m=148787047422954
Again, thanks for all the hard work. Best of luck.
When the SHA-1 collision was calculated earlier this year, Linus commented on git and SHA-1. No further questions, just sharing it here if you happened not to see it: https://marc.info/?l=git&m=148787047422954
Again, thanks for all the hard work. Best of luck.
This looks sweet. I bounce between using Bitbucket or Dropbox for private repos depending on my needs. Bitbucket has lots of features but is a little annoying to set up a new project. Dropbox is really easy but doesn't always work well (e.g. git push ends up being effectively async). Your version of it looks to be just as easy as Dropbox, maybe even easier, but without any of the downsides. And it's encrypted!
For those reading, you should under no circumstances use Dropbox as git hosting unless you're using git-remote-dropbox:
https://github.com/anishathalye/git-remote-dropbox
Hosing your repo is way too easy otherwise.
https://github.com/anishathalye/git-remote-dropbox
Hosing your repo is way too easy otherwise.
Does it matter much? If I hose my repo (which I don't think is that easy, since I've been doing this for years and never had an issue) then I can delete it and clone a new one from my local copy. Especially when it's just me, and I'm only pushing to the repo from one machine at a time.
It can hose your local, too. And it can happen easier than you think--I've seen it happen because a laptop that pushed to Dropbox went to sleep mid-sync and a desktop synced after. Fighting the Dropbox API to unwind it is a huge pain.
git-remote-dropbox works as you would expect a Git remote to work; it's API-driven and actively discourages even syncing the remote repository down to your machine. I would so, so strongly suggest you switch to it if you want to use Dropbox as a store.
Bare-git-repo-on-KBFS is inadvisable for a similar reason, which is why I'm so excited to see what they're doing here.
git-remote-dropbox works as you would expect a Git remote to work; it's API-driven and actively discourages even syncing the remote repository down to your machine. I would so, so strongly suggest you switch to it if you want to use Dropbox as a store.
Bare-git-repo-on-KBFS is inadvisable for a similar reason, which is why I'm so excited to see what they're doing here.
How would it hose my local? I thought git's design meant that it might possibly pull down new corrupted refs, but whatever I currently had would remain intact, so it's just a matter of reverting. Not so?
I believe it would be Dropbox doing the overwrite. Dropbox will just replace data - it doesn't do anything with respect to the reflog. I suppose it might be safer to work on a local copy and push to a second local copy in dropbox, so your working copy isn't touched by dropbox at all.
Yeah, keeping a local copy outside DB and pushing to a bare repo in DB is what I do. It didn't occur to me that one might work directly in a repository in DB. The hazards there, at least, are quite clear!
This is what I've done too, i.e use Dropbox for bare repos, and never had a problem.
OK, so maybe we're using "local" for different things. Are you developing in your local copy of Dropbox, or are you cloning to a local directory using the Dropbox directory as a source (probably bare)? I assumed the former, which is what I meant by "local"; you can end up syncing multiple different instances of the repo and horking the contents of your .git directory (as well as cross-edited files, etc, that bleed changes onto multiple branches).
Both have the possibility of breaking because of concurrent or delayed syncs--like, which is actually HEAD?--but the latter is probably safer than the former. Or you can just use git-remote-dropbox and never have a problem.
If you always, always-always, develop on a single computer, Dropbox-as-normal-file-system can be fine. But if you have a desktop and a laptop, or multiple people partying on it, I get worried. :)
Both have the possibility of breaking because of concurrent or delayed syncs--like, which is actually HEAD?--but the latter is probably safer than the former. Or you can just use git-remote-dropbox and never have a problem.
If you always, always-always, develop on a single computer, Dropbox-as-normal-file-system can be fine. But if you have a desktop and a laptop, or multiple people partying on it, I get worried. :)
That explains the confusion, I'm talking about keeping a bare repository in Dropbox and cloning it to a non-Dropbox location on each computer where I work. It never occurred to me to keep the working copy itself on DB, that would be silly!
I expect that this could break the bare repository on DB if I ever pushed from two places simultaneously (where "simultaneously" could potentially encompass a period of hours or days if I pushed from an offline computer) but I should be able to repair it by recreating the bare repository.
Using something like git-remote-dropbox seems like a good idea. But at this point, I can just start using Keybase, hooray!
I expect that this could break the bare repository on DB if I ever pushed from two places simultaneously (where "simultaneously" could potentially encompass a period of hours or days if I pushed from an offline computer) but I should be able to repair it by recreating the bare repository.
Using something like git-remote-dropbox seems like a good idea. But at this point, I can just start using Keybase, hooray!
> ...keep the working copy itself on DB, that would be silly!
I don't think it's necessarily silly; it can be very useful in some scenarios.
I keep all my local working copies in a folder synced across several machines. I use Resilio Sync because it is better[1] than Dropbox for this purpose, but it's basically equivalent.
What this lets me do is stop working suddenly, at any moment (baby crying upstairs, or I lost track of time and have to bike to the office for a meeting) get up from my computer and move to another one (in another room in my house, or across town at my employer's office).
The code doesn't have to be in any finished state, needn't compile, I can literally be right in the middle of a line of code. As long as I've saved my work to disk, it will have synced before I reach the next computer, so I can sit down and resume work.
Before I had kids I didn't need this as much, so I just did git push/pull.
But then you have to do the work of pushing your half-finished junk to a different private repo, or rebasing to avoid polluting the git history with a bunch of crap commits just because you had to move, or not do that and just accept having a git history filled with crap.
Frankly I wish more of my work was capable of being distributed like this, but it's really only suitable for collections of plain files, which are amenable to being synced file-by-file. Luckily that includes almost all my programming work, however.
[1]: Resilio Sync is better than Dropbox for this because: it is much faster to sync than Dropbox, it supports symlinks so it doesn't corrupt your data when syncing folders containing them, and it syncs my data only among computers I control, not to any cloud service.
I don't think it's necessarily silly; it can be very useful in some scenarios.
I keep all my local working copies in a folder synced across several machines. I use Resilio Sync because it is better[1] than Dropbox for this purpose, but it's basically equivalent.
What this lets me do is stop working suddenly, at any moment (baby crying upstairs, or I lost track of time and have to bike to the office for a meeting) get up from my computer and move to another one (in another room in my house, or across town at my employer's office).
The code doesn't have to be in any finished state, needn't compile, I can literally be right in the middle of a line of code. As long as I've saved my work to disk, it will have synced before I reach the next computer, so I can sit down and resume work.
Before I had kids I didn't need this as much, so I just did git push/pull.
But then you have to do the work of pushing your half-finished junk to a different private repo, or rebasing to avoid polluting the git history with a bunch of crap commits just because you had to move, or not do that and just accept having a git history filled with crap.
Frankly I wish more of my work was capable of being distributed like this, but it's really only suitable for collections of plain files, which are amenable to being synced file-by-file. Luckily that includes almost all my programming work, however.
[1]: Resilio Sync is better than Dropbox for this because: it is much faster to sync than Dropbox, it supports symlinks so it doesn't corrupt your data when syncing folders containing them, and it syncs my data only among computers I control, not to any cloud service.
For sure--I'm going to go poke at the Keybase one this afternoon! (Also, to be clear, the Keybase method is essentially the same as git-remote-dropbox. Both set up git remote helpers.)
It took me about two seconds to create a new repository with Keybase and clone it to my computer, so I'm pretty impressed so far.
Thanks for the info about git-remote-dropbox and the potential failure modes of going without, even if they don't all apply to the way I've been doing things. It's still not ideal, so here's hoping Keybase makes it obsolete. If not, I'll keep git-remote-dropbox in mind.
Thanks for the info about git-remote-dropbox and the potential failure modes of going without, even if they don't all apply to the way I've been doing things. It's still not ideal, so here's hoping Keybase makes it obsolete. If not, I'll keep git-remote-dropbox in mind.
transfer.fsckObjects=true
There's been talk of making this the default, but it's trivial enough to stick in your .git
There's been talk of making this the default, but it's trivial enough to stick in your .git
How does this compare to git-gpg, mentioned below in this thread?
https://news.ycombinator.com/item?id=15403360
https://news.ycombinator.com/item?id=15403360
See my comparison of Keybase Git, git-remote-gcrypt and git-gpg here: http://ptspts.blogspot.com/2017/10/comparison-of-encrypted-g...
Thanks for that.
Is Keybase Git all hype then? Because the alternatives seem a lot better.
To be honest, I'm not even sure I understand what Keybase _is_.
Is Keybase Git all hype then? Because the alternatives seem a lot better.
To be honest, I'm not even sure I understand what Keybase _is_.
> git doesn't check the validity of sha-1 hashes in your commit history.
What, like never? Or just not under specific circumstances?
I sure wouldn't want git to be doing that in every darn operation that traverses the history, like git log.
When receiving packets from another repo though, it would be useful.
What, like never? Or just not under specific circumstances?
I sure wouldn't want git to be doing that in every darn operation that traverses the history, like git log.
When receiving packets from another repo though, it would be useful.
What would I need to do to permit someone read-only, clear-text, non-public access to an encrypted repo? Can a combination of existing GIT / GitHub privileges and the Keybase solution help? If yes, and if you can add 2FA and we might be interested in becoming a customer.
Today your usecase can be solved ad-hoc by additionally manually signing what you push to keybase git, shared with the people you want to have read access.
If you want an encrypted storage solution with integrated read only access capabilities, I recommend using Tahoe-LAFS. You can probably store a git repository in it just fine.
If you want an encrypted storage solution with integrated read only access capabilities, I recommend using Tahoe-LAFS. You can probably store a git repository in it just fine.
It looks like you guys use react for a lot of your development. How do I know that you won’t push compromised code behind the scenes? Even unknowingly.
Btw your product is awesome! Multi platform encrypted team chat that doesn’t even need 4gb of ram :)
Btw your product is awesome! Multi platform encrypted team chat that doesn’t even need 4gb of ram :)
> hurdle of setting up team repositories with safe credential management...like for any kind of collaboration
Identity continues to be the key selling point of keybase. I'm excited by this.
I can keep clones of my private repositories here. Things like dotfiles and configurations. That sounds like a good start. And I can also easily share code to people who need to see it.
Identity continues to be the key selling point of keybase. I'm excited by this.
I can keep clones of my private repositories here. Things like dotfiles and configurations. That sounds like a good start. And I can also easily share code to people who need to see it.
Thank you and the rest of the Keybase team for your hard work!
Is it possible to use this on the Keybase mobile app for like note-taking?
Is it possible to use this on the Keybase mobile app for like note-taking?
Great work! I just happened to stumble into Mike Gerwitz's (2012) Horror Story [1] today about trust in git. This is great for safety.
[1] https://mikegerwitz.com/papers/git-horror-story
[1] https://mikegerwitz.com/papers/git-horror-story
> Interesting fact: git doesn't check the validity of sha-1 hashes in your commit history.
You mean, you have to run git fsck after pulling, since git only checks that you got what you asked for?
You mean, you have to run git fsck after pulling, since git only checks that you got what you asked for?
Thanks for making this - this is the first keybase product that I've gotten really excited about!
I'm really happy about this. I have private repos for personal information (e.g., tax spreadsheets going back a decade) that I keep synchronized across machines, and have to jump through hoops to get an encrypted authoritative remote source. Right now I do that with an encrypted partition on a private VM.
And, it really sucks that GitHub does not encrypt data at rest:
--- SNIP from https://help.github.com/articles/github-security ---
We do not encrypt repositories on disk because it would not be any more secure: the website and git back-end would need to decrypt the repositories on demand, slowing down response times. Any user with shell access to the file system would have access to the decryption routine, thus negating any security it provides. Therefore, we focus on making our machines and network as secure as possible.
--- SNIP ---
Encrypted disks are now the norm across various cloud providers, as is HTTPS. The crypto overheads are really low, and their benefits significantly outweigh the risks of leaving clear-text data on disks.
Also, defense-in-depth is always worth pursuing. The claim "it would not be any more secure", is so far from true, it's almost insulting to their target audience.
Keep killin' it, Keybase! Great job!
And, it really sucks that GitHub does not encrypt data at rest:
--- SNIP from https://help.github.com/articles/github-security ---
We do not encrypt repositories on disk because it would not be any more secure: the website and git back-end would need to decrypt the repositories on demand, slowing down response times. Any user with shell access to the file system would have access to the decryption routine, thus negating any security it provides. Therefore, we focus on making our machines and network as secure as possible.
--- SNIP ---
Encrypted disks are now the norm across various cloud providers, as is HTTPS. The crypto overheads are really low, and their benefits significantly outweigh the risks of leaving clear-text data on disks.
Also, defense-in-depth is always worth pursuing. The claim "it would not be any more secure", is so far from true, it's almost insulting to their target audience.
Keep killin' it, Keybase! Great job!
It certainly depends on the threat model, but in this case I have to agree with Github---adding at-rest encryption would be unlikely to make their product significantly more secure, and it would certainly be nowhere as secure as Keybase.
With Keybase, the data is encrypted on the client, and the keys stay on the client. Assuming the crypto is done right, there is fundamentally no way for Keybase to read the data, and therefore no way for an attacker to get the data by way of compromising Keybase. The only way for an attacker to get the data is by compromising the client machine, which is a very different threat model.
With the model you're proposing for Github, the data would be encrypted for transfer (via HTTPS or SSH), but then it would be immediately decrypted again on the server. Even if it is encrypted again before it's put onto the disk, fundamentally the key lives on the server (and has to in order to provide Github's feature set) and so an attacker who had compromised the machine would simply grab the key before going after the files on disk. The actual additional security you get is really not that significant.
Personally, I appreciate Github's stance on this. There have been a number of "secure" products (see e.g. Lavabit) that have really been snakeoil because they used the approach above. I'll take honesty over false promises any day---at least with the former, I understand my risk and can take steps to mitigate appropriately.
With Keybase, the data is encrypted on the client, and the keys stay on the client. Assuming the crypto is done right, there is fundamentally no way for Keybase to read the data, and therefore no way for an attacker to get the data by way of compromising Keybase. The only way for an attacker to get the data is by compromising the client machine, which is a very different threat model.
With the model you're proposing for Github, the data would be encrypted for transfer (via HTTPS or SSH), but then it would be immediately decrypted again on the server. Even if it is encrypted again before it's put onto the disk, fundamentally the key lives on the server (and has to in order to provide Github's feature set) and so an attacker who had compromised the machine would simply grab the key before going after the files on disk. The actual additional security you get is really not that significant.
Personally, I appreciate Github's stance on this. There have been a number of "secure" products (see e.g. Lavabit) that have really been snakeoil because they used the approach above. I'll take honesty over false promises any day---at least with the former, I understand my risk and can take steps to mitigate appropriately.
> Even if it is encrypted again before it's put onto the disk, fundamentally the key lives on the server (and has to in order to provide Github's feature set) and so an attacker who had compromised the machine would simply grab the key before going after the files on disk. The actual additional security you get is really not that significant.
It's not just compromised machines that you have to worry about -- that's what the higher layers of security are for:
It's also:
- poor disk decommissioning (e.g., your staff throws away disks without properly erasing them.) - poor machine management -- machines assigned to one owner, then moved to a new one. - bugs in storage management systems that leak data (e.g., block replicators, etc.)
Also, note that the keys don't have to be on disk. Most cloud providers configure hosts to get keys via PXE boot, for exactly this reason.
To be clear -- I don't disagree with you about thinking about the threat model, and in many cases it's not necessary to do this. But I do think that GitHub is now a very large player in an enterprise market, so I can't let them off so easily. :-)
It's not just compromised machines that you have to worry about -- that's what the higher layers of security are for:
It's also:
- poor disk decommissioning (e.g., your staff throws away disks without properly erasing them.) - poor machine management -- machines assigned to one owner, then moved to a new one. - bugs in storage management systems that leak data (e.g., block replicators, etc.)
Also, note that the keys don't have to be on disk. Most cloud providers configure hosts to get keys via PXE boot, for exactly this reason.
To be clear -- I don't disagree with you about thinking about the threat model, and in many cases it's not necessary to do this. But I do think that GitHub is now a very large player in an enterprise market, so I can't let them off so easily. :-)
Exactly.
The only thing that at-rest encryption would prevent is someone walking into a datacenter (or wherever the drives are physically stored) and nabbing one. An attacker is much more likely to gain access to a live system, where the data would be readily accessible.
The only thing that at-rest encryption would prevent is someone walking into a datacenter (or wherever the drives are physically stored) and nabbing one. An attacker is much more likely to gain access to a live system, where the data would be readily accessible.
At one point, DigitalOcean didn't scrub VM drives when reassigning to other customers unless you explicitly requested it (see https://news.ycombinator.com/item?id=6983097 for info). Using at-rest encryption would mean that the only thing that needs to be securely destroyed is the encryption key -- which shouldn't be stored on disk anyways -- at which point the contents of the drive are rendered meaningless.
Any bug (or poor security practices) at a cloud provider means that data not encrypted at rest could potentially leak to the next customer who the cloud provider assigns your old storage to. There's still a possibility for a cloud provider to leak data via lousy key management, but not storing unencrypted data greatly reduces the attack surface.
Any bug (or poor security practices) at a cloud provider means that data not encrypted at rest could potentially leak to the next customer who the cloud provider assigns your old storage to. There's still a possibility for a cloud provider to leak data via lousy key management, but not storing unencrypted data greatly reduces the attack surface.
Depends on who you are.... I know for us, physical datacenter security is tricky to ensure in a lot of countries, especially from government actors.
Out of curiosity: why do you keep such documents in repositories instead of simply in a filesystem (on an encrypted volume, backed up and possibly synced across devices)? Tax spreadsheets usually don't change, so there's no need for version history (if anything, new rows for new years are added, but without changing past data).
I ask this because I'm trying to figure out a solution for myself for keeping sensitive personal information and I never thought about storing such documents in a repository. Maybe I am missing something and your use case will open my eyes. Thanks!
I ask this because I'm trying to figure out a solution for myself for keeping sensitive personal information and I never thought about storing such documents in a repository. Maybe I am missing something and your use case will open my eyes. Thanks!
For me one big benefit is that it's distributed. I like to keep my important documents backed up on all the computers i have, on a USB drive stored in a safe location and also store the data with a cloud provider.
Now, if i update one document on computer A, and another document using computer B, i have to sync it to all other devices which is a PITA without git. You get into the situation where you don't know if the version on the USB drive was newer or older than the one on computer B etc, whereas with git all this is available in the version tree and there are nice merge tools available.
I've been planning to do this even for photos, for all the reasons above, but haven't taken the full step yet.
Now, if i update one document on computer A, and another document using computer B, i have to sync it to all other devices which is a PITA without git. You get into the situation where you don't know if the version on the USB drive was newer or older than the one on computer B etc, whereas with git all this is available in the version tree and there are nice merge tools available.
I've been planning to do this even for photos, for all the reasons above, but haven't taken the full step yet.
Wouldn't encrypted files with a service like Dropbox help? Containers usually sync well (only syncs changed parts). Only downside is that you can't access files without decryption software.
Dropbox, as all other "just-works" sync services, don't handle merge conflicts very good. Suddenly you have thousands of Filename_EditedByX(3).txt in every folder and dont know which one of them is the newest and don't have their most common ancestor version easily available for a 3-way merge.
To be fair, they cannot handle merge conflicts with encrypted containers. I find that merge conflicts almost always cause more trouble than the work of avoiding them from the start. As long as you don't share data (with containers unlikely), merge conflicts should be extremely rare (and anticipated).
I am not OP but I do the same as him.
I used to keep the data on Dropbox but switched to a repo because it felt to have better safety against user error. It's not all that hard to accidentally delete or modify a file in a filesystem. Given the commit process it's much harder to do in a repo.
I used to keep the data on Dropbox but switched to a repo because it felt to have better safety against user error. It's not all that hard to accidentally delete or modify a file in a filesystem. Given the commit process it's much harder to do in a repo.
My tax sheets are updated throughout the year for various reasons (bonuses, side gigs, property sales, etc.), so I rely on the version history. I also keep a lot of other stuff that I update more rapidly (mostly in text documents.)
Agree. Awesome way to keep dot files in sync across hosts without worrying about private github repos!
Wait, I think they are saying their backend integration such as forking through the web interface etc. would not work unless they decrypted your repo. Which makes sense - you should be using client software for all this!
Why don't more people use gitlab btw?
Why don't more people use gitlab btw?
Out of curiosity, what are the benefits you're talking about?
Has anyone seen a security audit of the Keybase platform? I love the product from a usability perspective, but have no idea if it's actually a safe repository for my team's key material.
This is exciting, but I'm new to Keybase and don't entirely understand it yet. How can I clone a Keybase-hosted repository on a remote server? Can gpg-agent proxy through ssh similarly to ssh-agent to allow access to GPG keys (and is that what keybase uses?), without having to store my keys on the remote server? Or would I need to create a new Keybase account just for the remote server, with that account's private keys stored on the server but at least segregated from my account's full access to communication, team-management, etc? Or would the best approach be to clone the Keybase-hosted repository locally and then push it to the remote server over SSH?
Yes, probably you need a new Keybase account just for that remote server if you want the remote server be able to do git pull after the initial git clone.
If all you need is a single git clone, and you already have a Keybase account, just do a git clone locally, and use rsync to upload the result to the remote server.
If all you need is a single git clone, and you already have a Keybase account, just do a git clone locally, and use rsync to upload the result to the remote server.
In case you're wondering...
> ~ Anticipated q's ~
> What if we're living in a simulation?
> Keybase offers no guarantees against sophisticated side-channel attacks by higher-level entities.
> ~ Anticipated q's ~
> What if we're living in a simulation?
> Keybase offers no guarantees against sophisticated side-channel attacks by higher-level entities.
It appears that this may no longer be an open question:
http://www.pbs.org/wgbh/nova/next/physics/physicists-confirm...
There was a Hacker News post about this a few days ago, likely from a different source, but I can't find it.
http://www.pbs.org/wgbh/nova/next/physics/physicists-confirm...
There was a Hacker News post about this a few days ago, likely from a different source, but I can't find it.
This only applies to classical computers not quantum, some combination of both, or by some means of computation we haven't discovered yet.
Doesn't this simply suggest that the reality that is simulating our universe would have to be fundamentally different than our own?
I remember reading something a decade or so ago which said that to simulate the entire known universe, even using selective windowing, would require more energy than the entire universe has. Wish I could remember the source.
> ~ Anticipated A's ~
> YES. IT'S LIKE THE MATRIX BUT INSTEAD OF ROBOTS IT'Z LIZARD PEOPLE.
> THIS ISN'T A QUESTION BUT GOOD POINT. WE R BEGINNING THE MOVE UNDERGROUND.
> YES. IT'S LIKE THE MATRIX BUT INSTEAD OF ROBOTS IT'Z LIZARD PEOPLE.
> THIS ISN'T A QUESTION BUT GOOD POINT. WE R BEGINNING THE MOVE UNDERGROUND.
Nice to see people work on git remote helpers, a shame that there's already a fine remote helper that is not tied to a specific hosting provider & uses GPG[0] already.
0: https://spwhitton.name/tech/code/git-remote-gcrypt/
0: https://spwhitton.name/tech/code/git-remote-gcrypt/
I came here precisely to see how this compares to git-remote-gcrypt (which I use to protect my password-safe filenames).
Anyone from keybase prepared to comment?
Anyone from keybase prepared to comment?
I'm not a Keybase developer, but I'm a user of Keybase Git, git-remote-gcrypt and git-gpg, and I've just written a comparison of the 3. Here you are:
http://ptspts.blogspot.com/2017/10/comparison-of-encrypted-g...
If I missed some of the aspects, please let me know.
http://ptspts.blogspot.com/2017/10/comparison-of-encrypted-g...
If I missed some of the aspects, please let me know.
Could you explain what's a shame? I'm having trouble guessing your point.
For anyone interested in alternatives, we built a utility (creatively named git-gpg) with the same goal: end-to-end encrypted git. It works over ssh, is self-hosted, and requires no additional software on the shared server.
https://github.com/glassroom/git-gpg
https://github.com/glassroom/git-gpg
This removes the ability for collaborating, browsing online, basically any feature of GitLab/GitHub/BitBucket.
... I think I'm in favor of this. I think of the things that those services provide on top of Git should actually be ported or mapped to Git itself. Branches, pull requests, comments, etc... should all be Git objects of some sort.
... I think I'm in favor of this. I think of the things that those services provide on top of Git should actually be ported or mapped to Git itself. Branches, pull requests, comments, etc... should all be Git objects of some sort.
GitHub pull requests actually are exposed as git objects (not the comments though, just the commits that make up the PR). If you want to see the commits in PR #515 you can just `git fetch origin pull/515/head`, or `git fetch origin pull/515/merge` to get the merge commit GitHub created when testing if your PR can be merged into the target branch.
Is this possible if the PR is coming from a fork?
It is.
To expand on this, you need to add the fork as an alternate remote (as opposed to origin), and then replace "origin" in the command posted prior.
So it's not possible from a fork, if you've only added the original repo as your single remote?
Currently I add the random person's fork as a remote to inspect/modify their PR branch. Was hoping for some GitHub magic to eliminate this step.
Currently I add the random person's fork as a remote to inspect/modify their PR branch. Was hoping for some GitHub magic to eliminate this step.
It is possible. You can specify a URL instead of a remote name for `git fetch`.
I thought it was in the PR destination repository (since they are under that repository's /pull namespace). You'd need to add the alternate remote if it's a PR into a fork (as opposed to from it), no?
You are absolutely correct. My apologies, as I understood the problem as "I have a fork and want to receive pull requests".
This can be a pretty common setup for some git workflows. Everybody makes a fork and takes / pushes pull requests or branches from their fork to others. The main advantage would be that if you have a lot of branches they don't all have to be on upstream and you don't need to have upstream permissions for everyone to push branches or changes to.
Nonetheless, I can see why my comment raised some confusion.
This can be a pretty common setup for some git workflows. Everybody makes a fork and takes / pushes pull requests or branches from their fork to others. The main advantage would be that if you have a lot of branches they don't all have to be on upstream and you don't need to have upstream permissions for everyone to push branches or changes to.
Nonetheless, I can see why my comment raised some confusion.
Have you seen https://github.com/google/git-appraise
Cool... haven't seen that. I guess what I'm asking for is for this stuff to become standardized. Once that happens if someone wants to write a web app around it that's fine, but it'd have to be run locally where the content can be decrypted and made sense of.
For another approach to managing API keys, secrets, and config with end-to-end encryption, check out EnvKey: https://www.envkey.com
Since it keeps secrets completely outside of git, you don't have to give up the convenience of collaboration tools by client-side encrypting the whole repository, and integration/deployment is simpler than maintaining a separate encrypted secrets repo.
Here's our Show HN from last week for more detail and discussion: https://news.ycombinator.com/item?id=15330757
Since it keeps secrets completely outside of git, you don't have to give up the convenience of collaboration tools by client-side encrypting the whole repository, and integration/deployment is simpler than maintaining a separate encrypted secrets repo.
Here's our Show HN from last week for more detail and discussion: https://news.ycombinator.com/item?id=15330757
Branches are Git objects. Incidentally, here's a distributed VCS that includes bug tracking: https://fossil-scm.org
No, branches are not git objects. An object is something that is identified by its sha1. Branches are merely files on the filesystem that point to objects.
You're thinking about branch names. The branch itself (anonymous branch?) is part of git because the commit history is a tree with branches.
It's part of git, but is not a git object, those have a very specific definition: it's all the thing that are identified by their hash.
Note that the commit history doesn't depend on branches: it's just a chain from commit to commits. The tree can exist withou any branch at all. That wouldn't be very useful, but it's still valid. Branches are merely pointers to a commit.
Note that the commit history doesn't depend on branches: it's just a chain from commit to commits. The tree can exist withou any branch at all. That wouldn't be very useful, but it's still valid. Branches are merely pointers to a commit.
> Branches are Git objects
That's not how I understand refs, they don't even live in the .git/objects hierarchy.
That's not how I understand refs, they don't even live in the .git/objects hierarchy.
You're correct, they're just files. To create a new branch off of master you can just...
cp .git/refs/heads/master .git/refs/heads/WTFFF
However what they point to are git objects. And being pointed to prevent them from being garbage collected (pruned).
I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself (which seemed to be the claim I was replying to).
Thanks for replying, I understand your position better now.
> I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself [in the GP]
The GP is mistaken. Their understanding of objects & refs seems different to how I've seen them refered to in the majority of git literature.
For passing readers: refs (branches and tags) are just git's way of labelling a commit (which are stored as objects). GitLab/GitHub don't do anything special to implement refs: they're standard git refs. They're not different, they're 100% part of git.
GitHub/GitLab do add a lot of extra refs to track things like PR/MRs.
> Branches, pull requests, comments, etc... should all be Git objects of some sort.
Branches can't be objects because you'd need a way to find them with a label, and then why not use the labels directly instead?
PRs and comments can be stored in a repo (as refs and notes), but git doen't have a strongly-opinionated view on the exact workflow you should follow when developing, and thus isn't interested in recommending that people should always use forks & CRs.
> I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself [in the GP]
The GP is mistaken. Their understanding of objects & refs seems different to how I've seen them refered to in the majority of git literature.
For passing readers: refs (branches and tags) are just git's way of labelling a commit (which are stored as objects). GitLab/GitHub don't do anything special to implement refs: they're standard git refs. They're not different, they're 100% part of git.
GitHub/GitLab do add a lot of extra refs to track things like PR/MRs.
> Branches, pull requests, comments, etc... should all be Git objects of some sort.
Branches can't be objects because you'd need a way to find them with a label, and then why not use the labels directly instead?
PRs and comments can be stored in a repo (as refs and notes), but git doen't have a strongly-opinionated view on the exact workflow you should follow when developing, and thus isn't interested in recommending that people should always use forks & CRs.
Right, there's no PRs/MRs in Git itself, but branches are there, specifically in that there's nothing about the existence of or use of branches in GitHub/GitLab that needs to be brought back into Git, that stuff is already there.
I recognize and accept the argument that it might be nice for Git to track merge-requests and issues (hence my link to Fossil SCM)
I recognize and accept the argument that it might be nice for Git to track merge-requests and issues (hence my link to Fossil SCM)
Somebody else said branches were already native to git. So are pull requests. Comments and issues are unlikely to be made native to git ever since git is developed primarily for the Linux kernel and their discussion channel is the mailing list.
Everyone should have been collaborating through distributed code review pushed into repo branches. Take a look at how SmartGit does it
It could be used for storing/fetching secrets and managing access for teams of real/application users.
Remember, it is impossible to delete cloud data with any kind of confidence, and your host may already be compromised.
Should be the epitaph of the current era of computing.
Should be the epitaph of the current era of computing.
As an aside, does key base offer tools to encrypt data from code, lets say from Python/Go/Rust/etc, that is moron proof?
I say tools, because while a library would be cool, I'd understand if it was a binary/application to provide the functionality/user-experience that key base is aiming for.
I know this likely doesn't sound like something key base should be aiming for, but to me, programmers need encryption just as much as users. I'd like to write my libraries/programs with encryption, but I also want to be able to trust it and not fear some inherent vulnerability I'm adding.
To me, Keybase is aiming to solve/reduce these complexities for users, and I'm hoping they also aim to solve it for developers to.
Thanks for all the hard work folks @ Keybase, it's definitely appreciated!
I say tools, because while a library would be cool, I'd understand if it was a binary/application to provide the functionality/user-experience that key base is aiming for.
I know this likely doesn't sound like something key base should be aiming for, but to me, programmers need encryption just as much as users. I'd like to write my libraries/programs with encryption, but I also want to be able to trust it and not fear some inherent vulnerability I'm adding.
To me, Keybase is aiming to solve/reduce these complexities for users, and I'm hoping they also aim to solve it for developers to.
Thanks for all the hard work folks @ Keybase, it's definitely appreciated!
This is a perfect use case for https://github.com/ofek/privy
Keybase has a public API [0]. There's a community Python library, but it appears to be unmaintained [1].
[0] https://keybase.io/docs/api/1.0/intro
[1] https://github.com/adamldoyle/python-keybase-client
[0] https://keybase.io/docs/api/1.0/intro
[1] https://github.com/adamldoyle/python-keybase-client
Check out libsodium/nacl. Go has an implementation of the box api[0] which is pretty foolproof. There are bindings and/or implementations in many languages.
[0]: https://godoc.org/golang.org/x/crypto/nacl
[0]: https://godoc.org/golang.org/x/crypto/nacl
Go has a good openpgp package: https://godoc.org/golang.org/x/crypto/openpgp
I wouldn't say it's foolproof though. I agree that simpler, higher-level libraries are needed across the board.
I wouldn't say it's foolproof though. I agree that simpler, higher-level libraries are needed across the board.
I have a private repo on GitHub which contains my dotfiles with SSH private keys, tokens, secrets and all kinds of secret stuff. I was uncomfortable storing it there, but my laziness/lack of time kept it there. Finally I will be able to encrypt the entire repo, yay!!
did you delete the unencrypted repo from github? actually even if you did, a version of it might still be lurking in some corner. Maybe time to create a new set of private keys?
Keybase has quite a few interesting and unique features. But I'm cautious, because it's not clear to me how they are going to monetize it.
Was expected one question but haven't found one: how it is actually encrypted? Any whitepaper or information how diffs could be handled over encrypted data? Or it is a just encrypted .git folder?
Looks like it's built on top of kbfs[1].
[1]: https://keybase.io/docs/kbfs/understanding_kbfs
[1]: https://keybase.io/docs/kbfs/understanding_kbfs
The "actually encrypted" part is NaCL (ED25519 + sha256) as supported by Go [2]. Interestingly, the common way to use
NaCL applies Curve25519 to encrypt a symmetric key which is the used for the payload. They don't do that. AFAICT, everything is using the ECC curve.
[2] https://keybase.io/docs/crypto/kbfs
[2] https://keybase.io/docs/crypto/kbfs
So they've rolled out their own encryption?
These benefits can be obtained by sharing a remote encrypted filesystem, in which sits an ordinary git repo.
Then simply check out that git repo using a file://path/to/repo reference, creating a clone on a local drive out of the encrypted volume.
The encrypted filesystem can then reside on an untrusted server in the cloud.
Ultimately, this is a cleaner solution than the whack-a-mole approach of hacking every application one by one to retrofit it with crypto storage capabilities.
Then simply check out that git repo using a file://path/to/repo reference, creating a clone on a local drive out of the encrypted volume.
The encrypted filesystem can then reside on an untrusted server in the cloud.
Ultimately, this is a cleaner solution than the whack-a-mole approach of hacking every application one by one to retrofit it with crypto storage capabilities.
This question has a FAQ entry near the bottom of TFA:
> Why not just make a bare repo in KBFS?
The Keybase filesystem journals changes and syncs them after writes, kind of like Dropbox. Which means you and another team member could be fighting each other and make a conflicted HEAD, where there'd be 2 copies side by side. Similarly, you shouldn't put git repos in Dropbox.
Keybase's git prevents this by locking.
Also: it's nicer to use the Keybase app to discover and manage your teams' repositories.
> Why not just make a bare repo in KBFS?
The Keybase filesystem journals changes and syncs them after writes, kind of like Dropbox. Which means you and another team member could be fighting each other and make a conflicted HEAD, where there'd be 2 copies side by side. Similarly, you shouldn't put git repos in Dropbox.
Keybase's git prevents this by locking.
Also: it's nicer to use the Keybase app to discover and manage your teams' repositories.
[deleted]
As I understand it, that's pretty much was Keybase has done here.
They have their encrypted filesystem, and this is a git remote helper for accessing that in a nice way (with access control built in on the fs layer).
I really like keybase, and I wish they could issue certs for me to sign PDFs. I would pay for that.
This is excellent. I've been looking for practical uses for my Keybase account -- it's been sitting around, verified but idle for years. The chat app is nice, but none of my friends or co-workers use the service (or understand crypto, for that matter).
Let me be unoriginal and sing your praises also. I'd LOVE to replace my use of Dropbox with Keybase, but I pretty much use every single feature of the iOS Dropbox App [1] and Keybase really isn't an alternative right now.
Also, one unique design choice of Dropbox is to use the underlying file system which means that working out of a Dropbox folder is native speed, even for high intensity IO. Keybase is a lot better than, say, Wuala was, but it's still noticeable.
[1] In prioritized order: camera uploads, viewing and editing plaintext, show photos, playing music and video, uploading to Dropbox from random other iOS apps, and finally selective offline access.
Also, one unique design choice of Dropbox is to use the underlying file system which means that working out of a Dropbox folder is native speed, even for high intensity IO. Keybase is a lot better than, say, Wuala was, but it's still noticeable.
[1] In prioritized order: camera uploads, viewing and editing plaintext, show photos, playing music and video, uploading to Dropbox from random other iOS apps, and finally selective offline access.
On Linux, you can try this encrypted Git without installing Keybase or using the Keybase GUI. You need the following Go binaries from keybase*.deb: keybase, git-remote-keybase and kbfsfuse.
Start kbfsfuse (specify a directory as a mount point); put get-remote-keybase to your $PATH; run keybase git create myrepo; you can stop kbfsfuse now; then this works (after substituting $KEYBASEUSER):
Start kbfsfuse (specify a directory as a mount point); put get-remote-keybase to your $PATH; run keybase git create myrepo; you can stop kbfsfuse now; then this works (after substituting $KEYBASEUSER):
git clone keybase://private/$KEYBASEUSER/myrepoAwesome... any plans to support LFS? I know with LFS you can write custom backend handlers.
Was just thinking that as well, the hard part about changing GitHub hosts like bitbucket/github is the feature parity between them. This is really enticing though.
First thing I thought of too. Would be an awesome feature.
Edit: Just tried and no dice: 'Remote "origin" does not support the LFS locking API.'
Edit: Just tried and no dice: 'Remote "origin" does not support the LFS locking API.'
Nice, this is perfect timing for me to see this actually. I've been slowly building out a little cli tool that I use to track .env files (and other files that you don't want to check into source) in a git repository that is parallel to your project's git repository.
The way it works is you identify a file that you don't want to check into source. The cli moves it to a parallel repo, commits the file to the parallel repo, and symlinks the file back to the original location.
From then on, you get all of the normal source control features like local changes, revision history, etc... that you get with every other file in your project. I basically got fed up with "crap what was that value I was using before? Let me dig through my credentials store" or resorting to commenting out old lines just in case I needed to revert.
So far, I've just been keeping those parallel repositories local for lack of an encrypted remote to push to. Definitely checking this out.
The way it works is you identify a file that you don't want to check into source. The cli moves it to a parallel repo, commits the file to the parallel repo, and symlinks the file back to the original location.
From then on, you get all of the normal source control features like local changes, revision history, etc... that you get with every other file in your project. I basically got fed up with "crap what was that value I was using before? Let me dig through my credentials store" or resorting to commenting out old lines just in case I needed to revert.
So far, I've just been keeping those parallel repositories local for lack of an encrypted remote to push to. Definitely checking this out.
It's amazing how many new features and even new complete products Keybase has been able to build on top of their core in such a short span of time. Even more so considering that a large part of that core is "just" a much better UX for a technology (GPG) that has existed for decades.
The two most interesting companies in crypto for me right now are KeyBase, and Wire.
I kind of wish there was some way for them to interact with each other, because it feels like they each have a piece of some bigger puzzle.
Are you not concerned with the data Wire collects?
https://news.ycombinator.com/item?id=14069674
Versus the data Signal collects:
https://signal.org/bigbrother/eastern-virginia-grand-jury/
Although I agree Wire looks like a much more (visually) polished chat service, it seems like they (Wire) collect more data than is necessary.
https://news.ycombinator.com/item?id=14069674
Versus the data Signal collects:
https://signal.org/bigbrother/eastern-virginia-grand-jury/
Although I agree Wire looks like a much more (visually) polished chat service, it seems like they (Wire) collect more data than is necessary.
Wire has open sourced it's server code (gplv3 even) and is working on federation support :
https://medium.com/@wireapp/wire-server-code-now-100-open-so...
So you can run your own copy of it, and be in complete control of any information it collects.
https://medium.com/@wireapp/wire-server-code-now-100-open-so...
So you can run your own copy of it, and be in complete control of any information it collects.
That seems really exciting. When that occurs I will most likely switch over. Unfortunately you can't quite host it your self yet: https://github.com/wireapp/wire-server/issues/2
is there some way to verify what was actually uploaded, and that it was indeed encrypted properly?
You can ask the same question about copying the .git directory with rsync over SSH, and the answer for that one applies to your original qustion as well:
* You can take a look at the packets (using e.g. tcpdump). * You can take a look at what the binaries (rsync, ssh vs. keybase and git-remote-keybase) read and write (using e.g. strace). * You can read the source code. * You can read the white papers and other analyses about the crypto used, and decide if you trust it.
The average user probably won't bother with these, because they need time, effort and experience.
If you can imagine a fundamentally better possible way for the average user to verify crypto, please let us know.
* You can take a look at the packets (using e.g. tcpdump). * You can take a look at what the binaries (rsync, ssh vs. keybase and git-remote-keybase) read and write (using e.g. strace). * You can read the source code. * You can read the white papers and other analyses about the crypto used, and decide if you trust it.
The average user probably won't bother with these, because they need time, effort and experience.
If you can imagine a fundamentally better possible way for the average user to verify crypto, please let us know.
This is amazing. I've been aware of KeyBase for some time now, but never really explored it. This is the push. Typing this comment as I am setting up my proofs.
I made a test repository and proceeded to clone it using the keybase:// uri, expecting it not to work, but by some dark magic, it just did. Impressive!
Not in my case.
$:~/projectes$ git clone keybase:// [uri] Cloning into 'something'... fatal: I don't handle protocol 'keybase'
I'm on an ubuntu machine. What can I do to solve the problem? Keybase version 1.0.34-20171006000413+5fe91ae13
$:~/projectes$ git clone keybase:// [uri] Cloning into 'something'... fatal: I don't handle protocol 'keybase'
I'm on an ubuntu machine. What can I do to solve the problem? Keybase version 1.0.34-20171006000413+5fe91ae13
Have you installed and are you running the keybase client software? I start it on my system (Arch Linux) using the run_keybase command.
Some hypothetical questions:
- How could CI/CD be set up? (Is read-only access possible to the repo? Would Keybase work on a Jenkins box? Could a deploy server verify signatures before deploying?)
- Could one set up mirroring to GitHub? How would this work? (I could see the signing without encryption as a value-add)
- What happens in the event of a force push? Could certain users destroy history?
- Could protected branches eventually be added, eg only certain users can push to master?
- How could CI/CD be set up? (Is read-only access possible to the repo? Would Keybase work on a Jenkins box? Could a deploy server verify signatures before deploying?)
- Could one set up mirroring to GitHub? How would this work? (I could see the signing without encryption as a value-add)
- What happens in the event of a force push? Could certain users destroy history?
- Could protected branches eventually be added, eg only certain users can push to master?
> - How could CI/CD be set up? (Is read-only access possible to the repo? Would Keybase work on a Jenkins box? Could a deploy server verify signatures before deploying?
You could have a deploy/CI user as a "reader" in your team. But we don't yet support hooks or anything (as that implies running arbitrary code on endhosts without their knowledge), so it would have to pull the repo.
> Could one set up mirroring to GitHub? How would this work? (I could see the signing without encryption as a value-add)
You can of course continue to use Github as a regular remote, but you'd lose all the encryption and signing unfortunately.
> - What happens in the event of a force push? Could certain users destroy history?
We do currently allow force pushes. Being able to turn that off on a repo-by-repo basis is something we'll consider in the future, definitely.
> Could protected branches eventually be added, eg only certain users can push to master?
Yes, but again, as with any "server"-side feature, this is complicated by the fact that it has to run on the client itself, and thus isn't really strictly enforceable against modified clients.
As we get more experience with people using this, we will definitely be thinking about how to make it better by adding power features like these. Thanks for the feedback!
You could have a deploy/CI user as a "reader" in your team. But we don't yet support hooks or anything (as that implies running arbitrary code on endhosts without their knowledge), so it would have to pull the repo.
> Could one set up mirroring to GitHub? How would this work? (I could see the signing without encryption as a value-add)
You can of course continue to use Github as a regular remote, but you'd lose all the encryption and signing unfortunately.
> - What happens in the event of a force push? Could certain users destroy history?
We do currently allow force pushes. Being able to turn that off on a repo-by-repo basis is something we'll consider in the future, definitely.
> Could protected branches eventually be added, eg only certain users can push to master?
Yes, but again, as with any "server"-side feature, this is complicated by the fact that it has to run on the client itself, and thus isn't really strictly enforceable against modified clients.
As we get more experience with people using this, we will definitely be thinking about how to make it better by adding power features like these. Thanks for the feedback!
This actually got me to signup for Keybase today.
I have a long running vm on Google cloud with only tiny configuration. I communicate to it with strong crypt way to access my 'pass' s git repo. So far so good, but I'm good to see what keybase's good work on how to improve the personal data safety, that's a good choice.
I could basically store all my sensitive data there? Passwords, SSNs, private keys of ETH wallets, etc.?
Yes
Hi security newbie here, I have private bitbucket repo for storing my pass data. One problem is that pass often leaks some metadata like headers of directories. From security standpoint does this mean it is more private to host the git repo on keybase versus bitbucket ?
That depends - is that data encrypted on your system? Since git is decentralized, there's a chance that any plain-text copy (such as a clone on your system) could be compromised. Keybase even addresses this in the FAQ, to an extent:
> What if my computer is compromised?
> Your work is only as safe as your endpoints, so we can't help you there.
This applies regardless of host or protocol, BTW, and it isn't even specific to computing. (It doesn't matter how many locks you have on your front door if you leave the back door propped open.)
> What if my computer is compromised?
> Your work is only as safe as your endpoints, so we can't help you there.
This applies regardless of host or protocol, BTW, and it isn't even specific to computing. (It doesn't matter how many locks you have on your front door if you leave the back door propped open.)
Hi pass uses gpg encryption on the text files my only concern are the file names which can leak meta info, for example just searching GitHub https://github.com/zurchpet/pass shows this person has passwords in a public repository but encrypted. Nevertheless I can see that the file names are credit card info and other sensitive info. It's like having a safe with a label "important stuff inside" ! Does keybase solve this problem ?
Yes, the contents of the git repository holding your pass files are encrypted, meaning that the file names are not visible to anyone without the private key (you).
You may also want to look at https://github.com/roddhjav/pass-tomb
You may also want to look at https://github.com/roddhjav/pass-tomb
Thanks for that I'll consider it.
From the article:
>> What are the limits?
> You can have as many repositories as you want, but the total for your personal repositories can't exceed 100GB. Each team also gets 100GB.
Is there anything stopping people from creating team after team just to hoard data in Keybase?
>> What are the limits?
> You can have as many repositories as you want, but the total for your personal repositories can't exceed 100GB. Each team also gets 100GB.
Is there anything stopping people from creating team after team just to hoard data in Keybase?
This is pretty cool. I've used git-crypt before to encrypt parts of a repo, but this approach seems much easier to manage.
https://github.com/AGWA/git-crypt
https://github.com/AGWA/git-crypt
I don't really understand how it works.
Are the git objects encrypted before being pushed? In that case how are they handled by the server? Does it accept them even though they make no sense? What Github is going to show?
Keybase is just another Git remote you can push to, one that transparently encrypts whatever is pushed to that remote.
The Git repo itself is completely normal in every other respect, so if you push to Github, everyone can still see the entire repo.
This is a good design as it lets people move repos easily and avoid too much lock-in, but it may (will...) come back to bite people soon, who push things to Github thinking they were "encrypted by Keybase", which is not what's going on.
The Git repo itself is completely normal in every other respect, so if you push to Github, everyone can still see the entire repo.
This is a good design as it lets people move repos easily and avoid too much lock-in, but it may (will...) come back to bite people soon, who push things to Github thinking they were "encrypted by Keybase", which is not what's going on.
If only their app did not have so many pages marked writable and executable...
Keybase, please just support web of trust already. In some way. Not everyone I want to be able to authenticate necessarily has public social media accounts.
Do they have a website/server?
#1. Host a file on your site
You can host a text file, such as yoursite.com/keybase.txt. This is preferred, if you have a website.
#2. Set a DNS TXT record
Instead of hosting a web page, you can place a keybase proof in your DNS records.
#1. Host a file on your site
You can host a text file, such as yoursite.com/keybase.txt. This is preferred, if you have a website.
#2. Set a DNS TXT record
Instead of hosting a web page, you can place a keybase proof in your DNS records.
> Do they have a website/server?
Not necessarily. I'm talking about people who want to remain anonymous (or pseudonymous) and might want to keep as low a public online profile as possible.
Not necessarily. I'm talking about people who want to remain anonymous (or pseudonymous) and might want to keep as low a public online profile as possible.
They support PGP, so you can use this.
They support PGP keys, but I don't think anything in the keybase UI or proofs will reflect key certifications made in PGP's web of trust. You can "track" people, but that's not the same thing.
It should be possible to augment the existing proofs with the WoT relationships, which could be valuable in a small number of cases.
However, it wouldn't surprise me if more people started using Keybase because of this one blog post, than have ever used PGP's web of trust features.
It should be possible to augment the existing proofs with the WoT relationships, which could be valuable in a small number of cases.
However, it wouldn't surprise me if more people started using Keybase because of this one blog post, than have ever used PGP's web of trust features.
[deleted]
This is amazing and convinced me to install Keybase on all my comps. I would like the ability to browse the repo in the Keybase app though.
My thanks to the keybase crew, I've waited for a practical PGP solution for nearly 20 years. Keybase delivers, thank you!
> Keybase team member here. Interesting fact: git doesn't check the validity of sha-1 hashes in your commit history.
Not sure I understand.
git clone blah
cd blah
git fsck
What am I missing?
Not sure I understand.
git clone blah
cd blah
git fsck
What am I missing?
Does this work for a local repository?
I'm confused. Is the entire repo encrypted, or some files only?
If the former, what are case where this is needed?
If the former, what are case where this is needed?
The entire repo is encrypted.
Consider a repo containing passwords. It's easy enough to encrypt the files containing the passwords but the names of the files or even the directories in which they're located are also info you might wish to hide, e.g. that you have an account at some-site-you-do-not-want-anyone-to-know-you-visit.com.
Consider a repo containing passwords. It's easy enough to encrypt the files containing the passwords but the names of the files or even the directories in which they're located are also info you might wish to hide, e.g. that you have an account at some-site-you-do-not-want-anyone-to-know-you-visit.com.
This is really friggin' cool! Best of luck to you guys, hope the work continues.
is there a way to view / verify that the payload has actually been encrypted?
Thanks for nice product. From now on I will move all my git repo into keybase
I give gitlab 2 months before they implement and launch encrypted git
just to clarify:
1. Do you need a private git repository?
2. Is everything really encrypted?
3. If everything is encrypted how can i access it through Git Desktop?
You can have team-based or private repos hosted by Keybase. Everything is encrypted and signed before it leaves your computer, and decrypted and verified when your computer downloads it. But your local checkout of that git repo is unencrypted. It's just a normal repo. So Github Desktop has full access to it, like it does for all files in your local filesystem.
Git repository are private for you or for a team that you select.
Yes, everything is encrypted on your machine locally.
Yes, everything is encrypted on your machine locally.
From what I understood (I haven't actually used the product), the repository is in the decrypted state on your local machine and is fully encrypted while being stored on the remote.
re: #1 I just tried it - they are giving you an encrypted git remote. So you create a new repo with them, then you can clone it somewhere (or add it as a remote) and push to it.
This is awesome, thanks for the heads up.
Yup!
Definitely not just posting this to verify myself.
Definitely not just posting this to verify myself.
Just wait til the government bans this because people will store kiddie porn, terrorist communications, and copyrighted media into it.
"Just wait til the government bans this because people will store kiddie porn, terrorist communications, and copyrighted media into it."
More precisely, the government will claim that ...
More precisely, the government will claim that ...
Fantastic!
Wait, what exactly _is_ keybase?
The home page says:
> Keybase is a new and free security app for mobile phones and computers.
ok, so, what does it do?
> For the geeks among us: it's open source and powered by public-key cryptography.
Still have no idea what it does ..
> Keybase is for anyone. Imagine a Slack for the whole world, except end-to-end encrypted across all your devices. Or a Team Dropbox where the server can't leak your files or be hacked.
ok, so what is it? what does it do?
> [picture that looks like a chat app]
So it's an encrypted chat server?
What is it?
How can you have a homepage for a product that doesn't talk about what the product is and what it does?
Why so obscure? Are you trying to hide something? Is this really a home page for a product aimed at people who care about security?
Compare it to, for example, tarsnap's[0] homepage, which explains exactly what the product does and doesn't leaving you wondering about anything.
[0]: https://www.tarsnap.com/
The home page says:
> Keybase is a new and free security app for mobile phones and computers.
ok, so, what does it do?
> For the geeks among us: it's open source and powered by public-key cryptography.
Still have no idea what it does ..
> Keybase is for anyone. Imagine a Slack for the whole world, except end-to-end encrypted across all your devices. Or a Team Dropbox where the server can't leak your files or be hacked.
ok, so what is it? what does it do?
> [picture that looks like a chat app]
So it's an encrypted chat server?
What is it?
How can you have a homepage for a product that doesn't talk about what the product is and what it does?
Why so obscure? Are you trying to hide something? Is this really a home page for a product aimed at people who care about security?
Compare it to, for example, tarsnap's[0] homepage, which explains exactly what the product does and doesn't leaving you wondering about anything.
[0]: https://www.tarsnap.com/
The first I ran into it, it was basically a key server where you could associate your public key with social media "proof" -- someone who had access to the private key proved it by posting from this Twitter account, this Github user, this Reddit user, etc.
It seems like the last year or two they've really been ramping up ways to actually _use_ those keys though. They do have a chat app, which I've used with coworkers, but only to share stuff we don't want to send over Slack. It seems like at least part of the issue they've got with the homepage is that their "core" product -- hosting a public key for someone -- isn't really very interesting compared to the satellite offerings.
It seems like the last year or two they've really been ramping up ways to actually _use_ those keys though. They do have a chat app, which I've used with coworkers, but only to share stuff we don't want to send over Slack. It seems like at least part of the issue they've got with the homepage is that their "core" product -- hosting a public key for someone -- isn't really very interesting compared to the satellite offerings.
It's a lot, isn't your third quote a pretty good description?
> Keybase is for anyone. Imagine a Slack for the whole world, except end-to-end encrypted across all your devices. Or a Team Dropbox where the server can't leak your files or be hacked.
It's not much of a reach to assume familiarity with Slack and Dropbox; the message is clearly that Keybase is those (via Keybase Chat & FS) but encrypted.
For what it's worth, it's also a keyserver, and (now) git remote.
> Keybase is for anyone. Imagine a Slack for the whole world, except end-to-end encrypted across all your devices. Or a Team Dropbox where the server can't leak your files or be hacked.
It's not much of a reach to assume familiarity with Slack and Dropbox; the message is clearly that Keybase is those (via Keybase Chat & FS) but encrypted.
For what it's worth, it's also a keyserver, and (now) git remote.
> isn't your third quote a pretty good description?
It's not. I think the person who wrote it think it's good marketing, but even that, it is not.
Here, try to see if this makes any sense as a product description:
> FeedHamster is for anyone! Imagine a Yelp that's customized just for you! Or a YouTube feed that only shows you interesting videos that _you_ would like!
> Install FeedHamster now!
Now, can you guess what FeedHamster does? Maybe it curates content? Honestly I have no idea. I just made it up. It doesn't really say anything useful at all, but I think it makes more sense that that description on Keybase's website.
It's not. I think the person who wrote it think it's good marketing, but even that, it is not.
Here, try to see if this makes any sense as a product description:
> FeedHamster is for anyone! Imagine a Yelp that's customized just for you! Or a YouTube feed that only shows you interesting videos that _you_ would like!
> Install FeedHamster now!
Now, can you guess what FeedHamster does? Maybe it curates content? Honestly I have no idea. I just made it up. It doesn't really say anything useful at all, but I think it makes more sense that that description on Keybase's website.
Tarsnap was a good example of a service selling to technically apt customer base. Guys who have years of IT training would love to read about deduplication and picodollars.
Keybase isn’t charging money to begin with, so “sales pitches” are not their primary concern.
Also, they are marketing to “the masses” with the idea that more people should have secure e2e encrypted communication and collaboration solutions where identity is cryptographically proven.
But if their welcome page started showing diagrams of encryption pathways and key derivation algorithm names with server client relationship diagrams, I guarantee no one besides people in tech will download it.
I still think they need to do better selling the idea to the masses, I in no way think their current front page is sufficient, but I understand that right now they aren’t concentrating on sales pitches.
Keybase isn’t charging money to begin with, so “sales pitches” are not their primary concern.
Also, they are marketing to “the masses” with the idea that more people should have secure e2e encrypted communication and collaboration solutions where identity is cryptographically proven.
But if their welcome page started showing diagrams of encryption pathways and key derivation algorithm names with server client relationship diagrams, I guarantee no one besides people in tech will download it.
I still think they need to do better selling the idea to the masses, I in no way think their current front page is sufficient, but I understand that right now they aren’t concentrating on sales pitches.
No, it's not. It says exactly nothing.
IMO opinion, the homepage is great - it covers the headlines. What it is missing is a link to a 'features' page that provides more details on the actual services and benefits.
Fundamentally, at this time your market is the more technically minded people who are going to want something a bit more concrete than "Imagine a Slack...".
Fundamentally, at this time your market is the more technically minded people who are going to want something a bit more concrete than "Imagine a Slack...".
I'm fairly new to Keybase, but essentially, at it's core, Keybase is a software/service for managing trust of identity/public keys, and easily sharing public keys with "trusted" parties, based on Keybase's trust model.
All of the other features you've mentioned are built on top of that key exchange, and use it to offer encrypted services.
All of the other features you've mentioned are built on top of that key exchange, and use it to offer encrypted services.
My read:
It's a product that's great for some security-oriented developers but hard to sell to others conceptually.
In order to make it appealing and useful to a more general audience, they've added extras which are comparable to Dropbox and Slack, just less featured and more secure.
Which seems a good approach given their constraints.
It's a product that's great for some security-oriented developers but hard to sell to others conceptually.
In order to make it appealing and useful to a more general audience, they've added extras which are comparable to Dropbox and Slack, just less featured and more secure.
Which seems a good approach given their constraints.
It's Jabberwocky.
My first initial gut thought is, could this be as a good ol cross platform method of password management? I've never been able to properly manage keepass due to syncing between different platforms being a pain.
https://www.passwordstore.org/
This might be exactly what you're looking for :)
This might be exactly what you're looking for :)
Maybe combine Keybase git with gopass, that one stores data in a git repo:
https://www.justwatch.com/gopass/#features
https://www.justwatch.com/gopass/#features
That sounds promising. I can't be the only one with this problem. (aka secure cross platform synchronized password management without requiring personal/managing cloud infrastructure.
This is something that I've been working on for about a year using Keybase[1].
[1]: https://github.com/kbsecret/kbsecret
[1]: https://github.com/kbsecret/kbsecret
https://github.com/kbsecret/kbsecret is Secrets management back by Keybase :)
Yes, it is. I'm already doing something similar with this Git encrypted remote helper:
- https://github.com/spwhitton/git-remote-gcrypt
Pass is a password manager that uses Git (or, rather, can use Git; it's optional) and I use the above-linked helper to configure a common remote repo (that's hosted in Dropbox) for all of my local copies of my password repo.
- https://github.com/spwhitton/git-remote-gcrypt
Pass is a password manager that uses Git (or, rather, can use Git; it's optional) and I use the above-linked helper to configure a common remote repo (that's hosted in Dropbox) for all of my local copies of my password repo.
I've had nothing but good experiences using 1Password.
No official/stable support for linux
the beta cli is available now, though it's more of an API than CLI. [1]
I've written a simple wrapper [2] to make it easy to use.
[1] https://support.1password.com/command-line-getting-started/
[2] https://github.com/dcreemer/1pass
I've written a simple wrapper [2] to make it easy to use.
[1] https://support.1password.com/command-line-getting-started/
[2] https://github.com/dcreemer/1pass
Try enpass.
https://www.enpass.io/
https://www.enpass.io/
Definitely heavily debating this. However, while not a hard requirement, the open source nature of keybase really draws me in.
Tried to create an account and no matter what I tried to name my devices all I got was "keybase has reserved this name."
Welp.
Welp.
Ah, it's not the device names that are reserved, it's the username itself.
Does it use libgcrypt?
https://www.theregister.co.uk/2017/07/04/gnupg_crypto_librar...
Maybe it only uses the Go crypto libraries?
https://www.theregister.co.uk/2017/07/04/gnupg_crypto_librar...
Maybe it only uses the Go crypto libraries?
Sounds intriguing but I'm missing the deep technical info on how it works.
> All data you push is signed by your device's private key, which never leaves your device.
For the reference git already supports signed pushes (git push --signed): https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...
> All data you push is signed by your device's private key, which never leaves your device.
For the reference git already supports signed pushes (git push --signed): https://github.com/git/git/commit/a85b377d0419a9dfaca8af2320...
Signing a commit does not encrypt that commit's contents, just adds a signature to prove you wrote that commit.
From the Keybase FAQ:
> So is this signing my commits?
> No, this is happening at a lower level, (1) to allow encryption, and (2) to ensure no unsigned or unencrypted data makes it in. Intuitively you can think of it as you and your teammates using a cryptographic secure storage layer for your git origin that doesn't really understand git.
> Your commits themselves are untouched from git's perspective, so if you mirror your repository elsewhere, it'll be a regular checkout.
From the Keybase FAQ:
> So is this signing my commits?
> No, this is happening at a lower level, (1) to allow encryption, and (2) to ensure no unsigned or unencrypted data makes it in. Intuitively you can think of it as you and your teammates using a cryptographic secure storage layer for your git origin that doesn't really understand git.
> Your commits themselves are untouched from git's perspective, so if you mirror your repository elsewhere, it'll be a regular checkout.
I did not mention signing commits but signing push requests and that was a reference to:
> All data you push is signed by your device's private key, which never leaves your device.
> All data you push is signed by your device's private key, which never leaves your device.
If you go crypto don't use git. It's not designed for cryptography in mind and the Keybase approach looks nice IF I can control every chain or can keep using github (or any other git server) with it. But for the storing part alone I would not trust Keybase.
I would even say if you do crypto and need cloud storage then store it in multiple places and avoid git. Better flat file and some daily backup strategy with e.g. encfs as the bottom layer. In worst case you get your data back.
Sorry keybase.... you are not a trustable cloud storage for me.
It feels like betting on your company... I want to bet on your company without feeling dependent on worst case restore scenarios (computer dying while your company dies).
Sorry keybase.... you are not a trustable cloud storage for me.
It feels like betting on your company... I want to bet on your company without feeling dependent on worst case restore scenarios (computer dying while your company dies).
> I want to bet on your company without feeling dependent on worst case restore scenarios
If you’re worried about Keybase disappearing with all your data, doesn’t backing up your computer cover that scenario?
If you’re worried about Keybase disappearing with all your data, doesn’t backing up your computer cover that scenario?
> But for the storing part alone I would not trust Keybase.
Why not? You're making a bunch of claims about this being bad but you're not providing any reasoning for it.
Why not? You're making a bunch of claims about this being bad but you're not providing any reasoning for it.
It's basically new closed source one bucket crypto on one company which is not known for storage. A little bit too much of uncertainty for my taste.
A large portion of their code is open source: https://github.com/keybase
How easy is it to build and run my own copy of this code, especially the server side stuff?
From an entrepreneurial perspective, this is my favorite thing we've done at Keybase. It pushes all the buttons: (1) it's relatively simple, (2) it's filling a void, (3) it's powered by all our existing tech, and (4) it doesn't complicate our product. What I mean by point 4 is that it adds very little extra UX and doesn't change any of the rest of the app. If you don't use git, cool. If you do, it's there for you.
What void does this fill? Previously, I managed some solo repositories of private data in a closet in my apartment. Who does that? It required a mess: uptime of a computer, a good link, and dynamic dns. And even then, I never could break over the hurdle of setting up team repositories with safe credential management...like for any kind of collaboration. With this simple screen, you can grab 5 friends, make a repo in a minute, and all start working on it. With much better data safety than most people can achieve on their own.