Keybase team member here. Interesting fact: 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. So even the fears about data leaks aside, this is a big win for safety.
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.
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.
> 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?
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.
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!
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?
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.
> 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.
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.
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.
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.
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!
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.
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 :)
> 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.
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:
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.
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.
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!
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!
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?
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.
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.
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.
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.
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.
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 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!!
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?
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.
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.
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):
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.
[+] [-] malgorithms|8 years ago|reply
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.
[+] [-] eropple|8 years ago|reply
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.
[+] [-] hannob|8 years ago|reply
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?
[+] [-] WorldMaker|8 years ago|reply
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.
[+] [-] rlpb|8 years ago|reply
By default. But set "git config --global transfer.fsckObjects true" and it will. No need to install anything else just for that.
[+] [-] Foxboron|8 years ago|reply
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...
[+] [-] eridius|8 years ago|reply
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?
[+] [-] sandGorgon|8 years ago|reply
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.
[+] [-] u801e|8 years ago|reply
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.
[+] [-] ianleeclark|8 years ago|reply
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.
[+] [-] rgbrenner|8 years ago|reply
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.
[+] [-] _spoonman|8 years ago|reply
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.
[+] [-] mikeash|8 years ago|reply
[+] [-] tosstossy|8 years ago|reply
There's been talk of making this the default, but it's trivial enough to stick in your .git
[+] [-] cs702|8 years ago|reply
https://news.ycombinator.com/item?id=15403360
[+] [-] kazinator|8 years ago|reply
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.
[+] [-] dheelus|8 years ago|reply
[+] [-] aey|8 years ago|reply
Btw your product is awesome! Multi platform encrypted team chat that doesn’t even need 4gb of ram :)
[+] [-] gaxun|8 years ago|reply
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.
[+] [-] tareqak|8 years ago|reply
Is it possible to use this on the Keybase mobile app for like note-taking?
[+] [-] rolandog|8 years ago|reply
[1] https://mikegerwitz.com/papers/git-horror-story
[+] [-] falsedan|8 years ago|reply
You mean, you have to run git fsck after pulling, since git only checks that you got what you asked for?
[+] [-] drudru11|8 years ago|reply
[+] [-] zeroxfe|8 years ago|reply
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!
[+] [-] eslaught|8 years ago|reply
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.
[+] [-] Remed|8 years ago|reply
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!
[+] [-] piggum|8 years ago|reply
[+] [-] EGreg|8 years ago|reply
Why don't more people use gitlab btw?
[+] [-] yorick|8 years ago|reply
[+] [-] theptip|8 years ago|reply
[+] [-] jack12|8 years ago|reply
[+] [-] chishaku|8 years ago|reply
> ~ Anticipated q's ~
> What if we're living in a simulation?
> Keybase offers no guarantees against sophisticated side-channel attacks by higher-level entities.
[+] [-] falsedan|8 years ago|reply
0: https://spwhitton.name/tech/code/git-remote-gcrypt/
[+] [-] RKlophaus|8 years ago|reply
https://github.com/glassroom/git-gpg
[+] [-] ericfrederich|8 years ago|reply
... 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.
[+] [-] eridius|8 years ago|reply
[+] [-] falsedan|8 years ago|reply
[+] [-] danenania|8 years ago|reply
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
[+] [-] ams6110|8 years ago|reply
Should be the epitaph of the current era of computing.
[+] [-] notheguyouthink|8 years ago|reply
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!
[+] [-] Walkman|8 years ago|reply
[+] [-] OrangeTux|8 years ago|reply
[+] [-] ex3ndr|8 years ago|reply
[+] [-] kazinator|8 years ago|reply
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.
[+] [-] phren0logy|8 years ago|reply
[+] [-] elahd|8 years ago|reply
[+] [-] FullyFunctional|8 years ago|reply
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.
[+] [-] ptspts|8 years ago|reply
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):
[+] [-] ericfrederich|8 years ago|reply
[+] [-] patrick_haply|8 years ago|reply
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.