Earlier quoted context omitted.
So I love Keybase unconditionally and if you guys weren't rolling in physical offices (and not one in Boston) I'd have been beating down your door to come work there--I think what Keybase is doing is important and it's something I'd love to work on. But I have a serious question that maybe you can answer, and it's something everybody who I've showed this to has asked me: How is Keybase gonna make money? How am I assu…
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…
Keybase launches encrypted Git
51–60 of 277 posts
Re: Keybase launches encrypted Git
#52Sounds 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...
From the Keybase FAQ:
> So is this signing my commits?
> No, this is happening at a lower level, (1) to allow encryption, and (2) to ensure no unsigned or unencrypted data makes it in. Intuitively you can think of it as you and your teammates using a cryptographic secure storage layer for your git origin that doesn't really understand git.
> Your commits themselves are untouched from git's perspective, so if you mirror your repository elsewhere, it'll be a regular checkout.
Re: Keybase launches encrypted Git
#53Keybase 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.
Re: Keybase launches encrypted Git
#54In 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.
> YES. IT'S LIKE THE MATRIX BUT INSTEAD OF ROBOTS IT'Z LIZARD PEOPLE.
> THIS ISN'T A QUESTION BUT GOOD POINT. WE R BEGINNING THE MOVE UNDERGROUND.
Re: Keybase launches encrypted Git
#55Keybase 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,…
Is it possible to use this on the Keybase mobile app for like note-taking?
Re: Keybase launches encrypted Git
#56My 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.
Re: Keybase launches encrypted Git
#57Sounds 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...
Signing a commit does not encrypt that commit's contents, just adds a signature to prove you wrote that commit. From the Keybase FAQ: > So is this signing my commits? > No, this is happening at a lower level, (1) to allow encryption, and (2) to ensure no unsigned or unencrypted data makes it in. Intuitively you can think of it as you and your teammates using a cryptographic secure storage layer for your git origin th…
> All data you push is signed by your device's private key, which never leaves your device.
Re: Keybase launches encrypted Git
#58Re: Keybase launches encrypted Git
#59Earlier quoted context omitted.
> 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.
Correct, but git doesn't recompute the hashes locally, so it wouldn't know they are wrong.
tree sha1
parent sha1 of parent I want to attach it to
author some string
committer some string
The commit message
I could add this to the git object store manually under the same sha1 file and a client could just fetch it? Would the client try to fetch the faked objects when it already has the real objects in its copy of the object store?That is, would it think it has the commit because the sha1 hasn't changed, but the tree sha1 has been updated and it would presumably refer to blobs that the client doesn't already have and try to fetch them. Or would it not proceed because it already has the commit?
Re: Keybase launches encrypted Git
#60Welp.