Thanks for nice product. From now on I will move all my git repo into keybase
Keybase launches encrypted Git
101–110 of 277 posts
Re: Keybase launches encrypted Git
#102As 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 m…
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.
Re: Keybase launches encrypted Git
#103My 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.
This is something that I've been working on for about a year using Keybase[1].
Re: Keybase launches encrypted Git
#104Keybase 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,…
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?
Re: Keybase launches encrypted Git
#105Earlier quoted context omitted.
Correct, but git doesn't recompute the hashes locally, so it wouldn't know they are wrong.
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.
Re: Keybase launches encrypted Git
#106This 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.
Re: Keybase launches encrypted Git
#107I'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/gi…
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 pe…
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.)
Re: Keybase launches encrypted Git
#108My 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.
I've had nothing but good experiences using 1Password.
Re: Keybase launches encrypted Git
#109Keybase 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,…
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.
Re: Keybase launches encrypted Git
#110If 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.…
> 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.