91–100 of 277 posts
In 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.
http://www.pbs.org/wgbh/nova/next/physics/physicists-confirm...
There was a Hacker News post about this a few days ago, likely from a different source, but I can't find it.
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.
Since it keeps secrets completely outside of git, you don't have to give up the convenience of collaboration tools by client-side encrypting the whole repository, and integration/deployment is simpler than maintaining a separate encrypted secrets repo.
Here's our Show HN from last week for more detail and discussion: https://news.ycombinator.com/item?id=15330757
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,…
Not sure I understand.
git clone blah
cd blah
git fsck
What am I missing?
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,…
What, like never? Or just not under specific circumstances?
I sure wouldn't want git to be doing that in every darn operation that traverses the history, like git log.
When receiving packets from another repo though, it would be useful.
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,…
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,…
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…
> How am I assured [?]
You're not, even if they start making money. Sucks, but true.
> You guys should be taking my money
One way to pay, if you want to help ensure their success & longevity, is to evangelize for them, and get other people hooked on their product. Getting other people hooked on it like you are and seeing the potential and get over the adoption humps... that's valuable! They're not taking money because it raises the barrier to entry, and growth is most important. Pay them by helping them grow.
If 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.…
If you’re worried about Keybase disappearing with all your data, doesn’t backing up your computer cover that scenario?
Then simply check out that git repo using a file://path/to/repo reference, creating a clone on a local drive out of the encrypted volume.
The encrypted filesystem can then reside on an untrusted server in the cloud.
Ultimately, this is a cleaner solution than the whack-a-mole approach of hacking every application one by one to retrofit it with crypto storage capabilities.