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

181–190 of 277 posts

Re: Keybase launches encrypted Git

#181

Post by mrsteveman1 »

Nala_Alan wrote: post #155
ris wrote: post #119

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.

They support PGP, so you can use this.

They support PGP keys, but I don't think anything in the keybase UI or proofs will reflect key certifications made in PGP's web of trust. You can "track" people, but that's not the same thing.

It should be possible to augment the existing proofs with the WoT relationships, which could be valuable in a small number of cases.

However, it wouldn't surprise me if more people started using Keybase because of this one blog post, than have ever used PGP's web of trust features.

Re: Keybase launches encrypted Git

#182

Post by FullyFunctional »

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.

Re: Keybase launches encrypted Git

#183

Post by pkamb »

ThatGeoGuy wrote: post #152
petetnt wrote: post #138

Earlier quoted context omitted.

It is.

To expand on this, you need to add the fork as an alternate remote (as opposed to origin), and then replace "origin" in the command posted prior.

So it's not possible from a fork, if you've only added the original repo as your single remote?

Currently I add the random person's fork as a remote to inspect/modify their PR branch. Was hoping for some GitHub magic to eliminate this step.

Re: Keybase launches encrypted Git

#184

Post by mrsteveman1 »

gwenzek wrote: post #75

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?

Keybase is just another Git remote you can push to, one that transparently encrypts whatever is pushed to that remote.

The Git repo itself is completely normal in every other respect, so if you push to Github, everyone can still see the entire repo.

This is a good design as it lets people move repos easily and avoid too much lock-in, but it may (will...) come back to bite people soon, who push things to Github thinking they were "encrypted by Keybase", which is not what's going on.

Re: Keybase launches encrypted Git

#185

Post by rolandog »

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

Great work! I just happened to stumble into Mike Gerwitz's (2012) Horror Story [1] today about trust in git. This is great for safety.

[1] https://mikegerwitz.com/papers/git-horror-story

Re: Keybase launches encrypted Git

#187

Post by swsieber »

ericfrederich wrote: post #46
falsedan wrote: post #40

Earlier quoted context omitted.

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

However what they point to are git objects. And being pointed to prevent them from being garbage collected (pruned).

Re: Keybase launches encrypted Git

#188

Post by rlpb »

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

> git doesn't check the validity of sha-1 hashes in your commit history.

By default. But set "git config --global transfer.fsckObjects true" and it will. No need to install anything else just for that.

Re: Keybase launches encrypted Git

#189

Post by biot »

rocmcd wrote: post #74
eslaught wrote: post #68

Earlier quoted context omitted.

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…

Exactly. The only thing that at-rest encryption would prevent is someone walking into a datacenter (or wherever the drives are physically stored) and nabbing one. An attacker is much more likely to gain access to a live system, where the data would be readily accessible.

At one point, DigitalOcean didn't scrub VM drives when reassigning to other customers unless you explicitly requested it (see https://news.ycombinator.com/item?id=6983097 for info). Using at-rest encryption would mean that the only thing that needs to be securely destroyed is the encryption key -- which shouldn't be stored on disk anyways -- at which point the contents of the drive are rendered meaningless.

Any bug (or poor security practices) at a cloud provider means that data not encrypted at rest could potentially leak to the next customer who the cloud provider assigns your old storage to. There's still a possibility for a cloud provider to leak data via lousy key management, but not storing unencrypted data greatly reduces the attack surface.

Post reply on HN