I give gitlab 2 months before they implement and launch encrypted git
Keybase launches encrypted Git
231–240 of 277 posts
Re: Keybase launches encrypted Git
#232Earlier 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…
Piggybacking off of the original question, I too have a question in this scope: With all the products you're offering, is there any indication which products will be staples of Keybase? Eg, I'm always hesitant of the "Google Product", where something gets added only to be abandoned ~1yr later after it doesn't gain the traction the company expected. For example, I'd love to get my wife and I switched to Keybase Chat f…
My best guess as an uninformed lurker and a Keybase user is that it's too early to know. You would have to know what's the impact of "sunsetting" features and for that you probably need more than 180k early adopters.
In case of chat you can always fallback to Telegram (I've done that after trying to move people to Wire).
In case of git you can always move the repo.
With the setup that's there now I can see how it could be used as the main origin along with a push to GitHub hook. Pull requests would be even mergable (blessed be Torvalds), though I'm not 100% sure if GitHub would pick up on that and autoclose the PR.
Re: Keybase launches encrypted Git
#233This 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.
Branches are Git objects. Incidentally, here's a distributed VCS that includes bug tracking: https://fossil-scm.org
No, branches are not git objects. An object is something that is identified by its sha1. Branches are merely files on the filesystem that point to objects.
Re: Keybase launches encrypted Git
#234Keybase 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.
Who actually does that though? I'm guessing less than 1% of users. Any idea why it isn't on by default?
Re: Keybase launches encrypted Git
#235Earlier quoted context omitted.
> Branches are Git objects That's not how I understand refs, they don't even live in the .git/objects hierarchy.
I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself (which seemed to be the claim I was replying to).
Thanks for replying, I understand your position better now.
> I guess I don't understand what GitHub/GitLab does that makes branches different from Git itself [in the GP]
The GP is mistaken. Their understanding of objects & refs seems different to how I've seen them refered to in the majority of git literature.
For passing readers: refs (branches and tags) are just git's way of labelling a commit (which are stored as objects). GitLab/GitHub don't do anything special to implement refs: they're standard git refs. They're not different, they're 100% part of git.
GitHub/GitLab do add a lot of extra refs to track things like PR/MRs.
> Branches, pull requests, comments, etc... should all be Git objects of some sort.
Branches can't be objects because you'd need a way to find them with a label, and then why not use the labels directly instead?
PRs and comments can be stored in a repo (as refs and notes), but git doen't have a strongly-opinionated view on the exact workflow you should follow when developing, and thus isn't interested in recommending that people should always use forks & CRs.
Re: Keybase launches encrypted Git
#236Earlier 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…
The enterprise would be a valid target, but if you really want them to trust you, you'll need to offer localized hosting (host from EU, Russian, Chinese datacenters) as well as on-premise hosting. Actually, in that last one you should probably also offer consultancy to set up the servers securely - both software and physical hardware security. Secure software isn't worth much if the systems it runs on is compromised.…
> localized hosting
IIRC it boils down to a new Merkle root and a self-hosted server instance that uses it. Add snapshot pushing to the blockchain and you've got yourself an independent Keybase instance with a fresh and clean database ready to be filled with employees.
I wonder what the identity proof adding would look like. I guess corporations are not interested in public proofs from Twitter.
Re: Keybase launches encrypted Git
#237Keybase 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,…
I will pay a LOT of money if you can slap a half decent web interface on it. Surprisingly, you guys look like a direct clone of the new Bitbucket interface. Its not my favorite (I like github so much better) - but Bitbucket with its inbuilt Pipelines integrations is so much better than Github.
But how will their web server present that data? They can't read the data.
Re: Keybase launches encrypted Git
#238Earlier quoted context omitted.
Branches are Git objects. Incidentally, here's a distributed VCS that includes bug tracking: https://fossil-scm.org
No, branches are not git objects. An object is something that is identified by its sha1. Branches are merely files on the filesystem that point to objects.
You're thinking about branch names. The branch itself (anonymous branch?) is part of git because the commit history is a tree with branches.
Re: Keybase launches encrypted Git
#239This 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.
Everyone should have been collaborating through distributed code review pushed into repo branches. Take a look at how SmartGit does it
Re: Keybase launches encrypted Git
#240I'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: why do you keep such documents in repositories instead of simply in a filesystem (on an encrypted volume, backed up and possibly synced across devices)? Tax spreadsheets usually don't change, so there's no need for version history (if anything, new rows for new years are added, but without changing past data). I ask this because I'm trying to figure out a solution for myself for keeping sensitive pe…
I am not OP but I do the same as him.
I used to keep the data on Dropbox but switched to a repo because it felt to have better safety against user error. It's not all that hard to accidentally delete or modify a file in a filesystem. Given the commit process it's much harder to do in a repo.