from Hacker News

Keybase launches encrypted Git

by aston on 10/4/17, 3:36 PM with 270 comments

  • by malgorithms on 10/4/17, 4:39 PM

    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.

  • by zeroxfe on 10/4/17, 4:53 PM

    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!

  • by theptip on 10/4/17, 11:47 PM

    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.

  • by jack12 on 10/4/17, 7:35 PM

    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?

  • by chishaku on 10/4/17, 5:16 PM

    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.

  • by falsedan on 10/4/17, 5:25 PM

    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/

  • by RKlophaus on 10/4/17, 6:59 PM

    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

  • by ericfrederich on 10/4/17, 5:07 PM

    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.

  • by ams6110 on 10/4/17, 9:41 PM

    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.

  • by notheguyouthink on 10/4/17, 5:38 PM

    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!

  • by Walkman on 10/4/17, 6:00 PM

    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!!

  • by OrangeTux on 10/4/17, 5:29 PM

    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.

  • by ex3ndr on 10/4/17, 9:50 PM

    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?

  • by kazinator on 10/4/17, 7:37 PM

    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.

  • by phren0logy on 10/4/17, 5:43 PM

    I really like keybase, and I wish they could issue certs for me to sign PDFs. I would pay for that.

  • by elahd on 10/4/17, 5:02 PM

    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).

  • by FullyFunctional on 10/5/17, 12:09 AM

    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.

  • by ptspts on 10/6/17, 9:16 AM

    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):

      git clone keybase://private/$KEYBASEUSER/myrepo

  • by ericfrederich on 10/4/17, 5:03 PM

    Awesome... any plans to support LFS? I know with LFS you can write custom backend handlers.

  • by patrick_haply on 10/5/17, 6:04 AM

    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.

  • by rcthompson on 10/5/17, 4:00 AM

    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.

  • by AdrianRossouw on 10/4/17, 9:47 PM

    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.

  • by payomdousti on 10/4/17, 8:19 PM

    is there some way to verify what was actually uploaded, and that it was indeed encrypted properly?

  • by TomasHubelbauer on 10/4/17, 8:31 PM

    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.

  • by jboynyc on 10/4/17, 11:12 PM

    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!

  • by philip1209 on 10/4/17, 8:47 PM

    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?

  • by iamthirsty on 10/4/17, 9:23 PM

    This actually got me to signup for Keybase today.

  • by ryanqian on 10/5/17, 4:49 AM

    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.

  • by earlybike on 10/4/17, 7:55 PM

    I could basically store all my sensitive data there? Passwords, SSNs, private keys of ETH wallets, etc.?

  • by j7ake on 10/4/17, 4:54 PM

    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 ?

  • by ValentineC on 10/5/17, 4:23 PM

    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?

  • by tln on 10/4/17, 4:55 PM

    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

  • by gwenzek on 10/4/17, 6:52 PM

    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?

  • by WindowsFon4life on 10/4/17, 7:20 PM

    If only their app did not have so many pages marked writable and executable...

  • by ris on 10/4/17, 8:11 PM

    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.

  • by ryanpcmcquen on 10/11/17, 5:06 PM

    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.

  • by squashmode on 10/4/17, 11:43 PM

    My thanks to the keybase crew, I've waited for a practical PGP solution for nearly 20 years. Keybase delivers, thank you!

  • by jancsika on 10/4/17, 7:28 PM

    > 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?

  • by hollander on 10/4/17, 7:02 PM

    Does this work for a local repository?

  • by dorfsmay on 10/4/17, 7:59 PM

    I'm confused. Is the entire repo encrypted, or some files only?

    If the former, what are case where this is needed?

  • by gigatexal on 10/4/17, 7:21 PM

    This is really friggin' cool! Best of luck to you guys, hope the work continues.

  • by payomdousti on 10/4/17, 8:20 PM

    is there a way to view / verify that the payload has actually been encrypted?

  • by voanhduy1512 on 10/4/17, 7:37 PM

    Thanks for nice product. From now on I will move all my git repo into keybase

  • by zrg on 10/5/17, 11:46 AM

    I give gitlab 2 months before they implement and launch encrypted git

  • by paule89 on 10/4/17, 6:46 PM

    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?

  • by Zynjec on 10/5/17, 12:52 AM

    This is awesome, thanks for the heads up.

  • by daveheq on 10/5/17, 5:07 AM

    Just wait til the government bans this because people will store kiddie porn, terrorist communications, and copyrighted media into it.

  • by LeicaLatte on 10/4/17, 9:13 PM

    Fantastic!

  • by hasenj on 10/5/17, 4:12 AM

    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/

  • by NikolaeVarius on 10/4/17, 5:03 PM

    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.

  • by adiosdfisndf on 10/4/17, 6:03 PM

    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.

  • by feelin_googley on 10/5/17, 3:28 PM

    Does it use libgcrypt?

    https://www.theregister.co.uk/2017/07/04/gnupg_crypto_librar...

    Maybe it only uses the Go crypto libraries?

  • by aauthespian on 10/4/17, 11:03 PM

  • by hdhzy on 10/4/17, 5:47 PM

    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...

  • by therealmarv on 10/4/17, 6:53 PM

    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).