Live data from Hacker News

Keybase launches encrypted Git

keybase.io

41–50 of 277 posts

Re: Keybase launches encrypted Git

#41

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.

Have you seen https://github.com/google/git-appraise

Re: Keybase launches encrypted Git

#42
post #25
post #18

Earlier quoted context omitted.

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.

This is what I've done too, i.e use Dropbox for bare repos, and never had a problem.

Re: Keybase launches encrypted Git

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

Re: Keybase launches encrypted Git

#45
post #6

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/gi…

Out of curiosity, what are the benefits you're talking about?

Re: Keybase launches encrypted Git

#46

Earlier quoted context omitted.

Branches are Git objects. Incidentally, here's a distributed VCS that includes bug tracking: https://fossil-scm.org

> Branches are Git objects 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
... no SHA-1 involved at all, no parent, history, etc.

Re: Keybase launches encrypted Git

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

Re: Keybase launches encrypted Git

#48

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.

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.

Re: Keybase launches encrypted Git

#49

Earlier quoted context omitted.

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…

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

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.

Re: Keybase launches encrypted Git

#50

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

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

Post reply on HN