Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Keybase launches encrypted Git

keybase.io

Post reply on HN
Print view View original

11–20 of 277 posts

Re: Keybase launches encrypted Git

#11

Post by eropple »

mikeash wrote: post #7
malgorithms wrote: post #2

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,…

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.

Re: Keybase launches encrypted Git

#12

Post by elahd »

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

Re: Keybase launches encrypted Git

#15

Post by mikeash »

eropple wrote: post #11
mikeash wrote: post #7

Earlier quoted context omitted.

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.

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.

Re: Keybase launches encrypted Git

#16

Post by eropple »

mikeash wrote: post #15
eropple wrote: post #11

Earlier quoted context omitted.

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.

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.

Re: Keybase launches encrypted Git

#17

Post by ericfrederich »

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.

Re: Keybase launches encrypted Git

#18

Post by mikeash »

eropple wrote: post #16
mikeash wrote: post #15

Earlier quoted context omitted.

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 stron…

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?

Re: Keybase launches encrypted Git

#19

Post by tehno »

NikolaeVarius wrote: post #13

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.

Maybe combine Keybase git with gopass, that one stores data in a git repo:

https://www.justwatch.com/gopass/#features

Re: Keybase launches encrypted Git

#20

Post by eropple »

mikeash wrote: post #18
eropple wrote: post #16

Earlier quoted context omitted.

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 stron…

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?

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

Post reply on HN