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, (2) it's filling a void, (3) it's powered by all our existing tech, and (4) it doesn't complicate our product. What I mean by point 4 is that it adds very little extra UX and doesn't change any of the rest of the app. If you don't use git, cool. If you do, it's there for you.

What void does this fill? Previously, I managed some solo repositories of private data in a closet in my apartment. Who does that? It required a mess: uptime of a computer, a good link, and dynamic dns. And even then, I never could break over the hurdle of setting up team repositories with safe credential management...like for any kind of collaboration. With this simple screen, you can grab 5 friends, make a repo in a minute, and all start working on it. With much better data safety than most people can achieve on their own.

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 assured that this, and everything else in my Keybase storage, is going to be there in six months? Like, I still have a private server in a closet in my apartment that syncs all the stuff I trust Keybase with because I don't know what the business-side failure case is.

You guys should be taking my money, is what I'm saying. Also probably hiring me. But definitely taking my money.

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 want to use Keybase for free - and companies.

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. Fortunately that just can't work with Keybase, so no fears there.

But charging for anything on Keybase right now would be a big mistake. We only have ~180,000 users, and we want to bring crypto to everyone. That basically means making products we believe are better.

Another way of looking at your concern: I think if we were charging right now, it wouldn't actually decrease the odds we disappeared in a few years. It might distract our attention from working on the best product and cause our bloody demise. So maybe we're not choosing the path that gives you the highest impression of safety, but I think we actually are.

That being said, I think Keybase is one of the most important companies around right now. I would gladly pay $10/month, even if literally all it did was put a "Supporter" badge on my profile. I'm sure hundreds of other people agree.

My comment that started this subthread is in my top ten, and I have been here entirely too long, so, yeah. Keybase is good. It staying around is important. People around here, at least, seem to know it, and that's awesome.

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 from Telegram. With that said, I love the features of Telegram, they're killing it for me honestly, but I can't expect Keybase to compete with Telegram unless they're really invested in it.

So which products from Keybase are one-off experiments, and which are long-roadmapped products - expected to have continued development and support for years to come? I'm having trouble understanding what to trust.

Note, none of this is critical to Keybase. I'm wary of startups in general, despite loving you guys, so I'm just seeking understanding. I appreciate whatever information you can give me, even if small :)

Signal only provides chat functionality... And doesn't support multiple devices... Also the history is lost on device change (or upgrade/reset etc)... And you cannot chat with people who you don't trust with your phone number

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.

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. Consultancy can be worth a lot of money, if your customers think it's worth it.

I'd start working on offering a paid enterprise solution soon tbf. I'd also tweak your landing page, the blurb is "a new and free security app"; the "new and free" doesn't instill much trust, and the "security app" doesn't really describe what it does. The second phrase tries to explain that "it's Slack" or "it's Dropbox", which I guess is fair, but I'd aim towards distancing yourself and describe it as e.g. "End-to-end encrypted communications and file sharing". What makes Keybase unique? I mean Dropbox has a pretty solid security page (https://www.dropbox.com/business/trust/security/architecture), as does Slack (https://slack.com/security).

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.

I'm (unfortunately, at times) intimately familiar with what big corporate IT departments look for in terms of features, authentication, RBAC, auditing, etc., etc. in "Enterprise" products and if you need it I'd be willing to help you understand what we look for and why. Feel free to drop me a line. Either way, I love what you're doing and I hope you nail it.

OK, awesome. I'm glad you wrote this, because this makes me feel a heck of a lot better about using Keybase. This was in a way my hunch, but I figured--this is something good and cool, I want to make sure it stays good and cool. =) Thanks for the reply.

This is a fantastic answer, and I wish more folks were this dedicated to making sure they have something great before trying to hawk it. That said, I do wish I could pay for (at least) a TB of Keybase storage right now. :D

> That means that our highest priority is removing any obstacles to adoption. Anything that people might use as a reason not to use Trello has to be found and eliminated.

In this case I am weary of using something like this that is free because I have seen so many things in the past that were free only to shutdown rapidly after they grew in size, but with no way to pay for themselves and had to pivot or sell out. So being free is actually an obstacle in adoption.

I am intimately aware of this frustration, but what's the alternative? Stable companies also kill or abandon projects. The whole software and consumer product ecosystems are constantly churning.

Personally I'm old enough that I don't have to try every new service, but if something is solving a real problem in the short-term, I will give it a try and hope for the best. Keybase is definitely in this bucket. Worst case they go away and I have to come up with a different solution, but right now it's adding tremendous value.

but what's the alternative? Stable companies also kill
or abandon projects.

The alternative is products which, considered in isolation and with all costs taken into account, produce more revenue than they cost to maintain.

Nobody shuts down a project that costs $500,000 per annum and brings in $1,000,000 per annum.

Of course, 'all costs' there doesn't just mean employee salary - it has to include difficult-to-measure costs like the opportunity costs of the attention it demands from executives, paying a portion of the support costs of any legacy systems it needs, and suchlike.

It seems to me that there's a lot of product opportunities in the corporate world that go beyond what Keybase is providing today. Chat and Git are interesting, but there's already a lot of momentum in both these areas. Been thinking how I use encryption and where things fall short today. One of those areas is build signing and hardware key management for our team.

Everything that goes on our servers get signed by an official PGP key. Only a couple people can sign builds, and each has a Yubikey with PGP subkeys on it. This is kind of annoying to manage. We use an airgapped computer that houses the private key, can create subkeys and assign to Yubikeys, can handle expiration management, etc. When we want to deal with this, we have to get the computer, unlock access, and deal with the command line. This is error-prone and annoying. Having a solution that allows for safe storage of a private key and easy management of subkeys on smartcards would be amazing without the need for an airgapped computer and a command line would be really interesting.

(The signing/verification part can probably be handled today by the keybase tool.)

Okay, that's maybe more specialized. Let's move away from paranoid server builds and go toward something similar that's gotten plenty of companies in trouble: Malicious e-mails. How often are we hearing about some poor employee receiving an e-mail that appears to come from a co-worker that contains a finance document with a trojan? Or maybe just a simple document with a form, instructions, and a link that results in information leaked to some third-party?

If there was a dead-simple way to sign and validate documents over Keybase (and I mean dead-simple, built for people who only know Word and Excel), for use in e-mail and document management, with marketing around "For $XX/user/month, you don't have to worry about getting hacked," I bet plenty of companies would bite.

I don't know what that looks like exactly, but just playing around loosely with some thoughts, it would be interesting (particularly for fully IT-managed systems) to have a Keybase Shield product that would automate much of the signing and verification of documents. It could tie into Word, Excel, etc. via their plugin interface and sign on save, and/or provide a big "Sign this document" widget on the side of the screen that a document can be dropped onto (or a Share action on phones). It'd then own the file associations for these documents, intercepting them when opening via e-mail or file servers, and would validate their signature. A document from the outside world (or one not going through the corporate-mandated signature process) would outright fail to open with an error message and instructions to ask the sender to please sign the document.

(Lots of details to work out there, but if this process could be made simple and mostly automatic, you'd help close a major attack vector that companies are susceptible to today.)

Anyway, it's great hearing your thoughts on how Keybase plans to make money. I've been in the same boat of loving Keybase but being uncertain about where it'll be 5 years from now. We'll keep an eye open for some paid products :)

On the document management end of things: that's exactly what the public/yourname/ subdirectory of KBFS is-- every document there gets signed when edited, then they're automatically verified (by the KBFS client) when someone tries to download them (either the original author, or another Keybase user).

There's no explicit signing process involved, but that's part of Keybase's value proposition: automatic and transparent public key cryptography.

If you can tie the shield into KBFS, that's even better. It's not enough to protect a company from attacks, though. People may still click that random document coming in via e-mail that claims to be from a co-worker. A mandatory technical solution on that end, no matter what the actual technology looks like under the hood, would be essential for protecting people from making these kinds of mistakes.

The value proposition of automatic and transparent public key cryptography is strong, and what I love about Keybase. Just thinking of other ways that can be applied transparently.

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

It doesn't have to be a fake page, talking about a mvp where they can gauge who is interested in paying and what their problems are so they can concentrate in those areas. When confident they could even setup a simple paypal re-occuring sale system too.

Completely agreed. The reason I don't use Keybase more than I do is because I half expect them to be acquired/something else to happen. Would gladly give them my $10/mo. for a 1TB instead of Dropbox.

With that said, I completely understand why they aren't right now -- maybe they're not going after the consumer market, maybe they don't want to box themselves in with customer support obligations, etc. But I really would like to use them.

@malgorithm's answer is fantastic, just wanted to add some side-comments...

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

It's valuable, but not in the capital sense. Each person you get hooked on their product increases their burn rate, and both makes them more attractive as an acquisition (which is scary for users) and more desperate for cash (which makes acquiescing to acquisition more tempting).

Without a road to profitability (or at least a road to revenue) even attracting equity is difficult; investors who enter with that knowledge will be looking to exit through acquisition, since that's basically the only way to exit, other than just getting more capital.

100% agreed. Hosting sensitive git repositories is problem that companies and people are willing to pay $$$ for and stuff that is free has a tendency to go away after a few years. Heck don't bother putting any technical work into it or anything (aka work) and continue being free, but allow me to have a "paying account" or whatever. Pretty much if you are providing value let me prove it by giving you some cash.

> Keybase team member here. Interesting fact: git doesn't check the validity of sha-1 hashes in your commit history.

I heard this a couple of times and tried to confirm it a while ago, but was unable to. I wasn't able to forge a repository with faulty hashes in it.
I also heard plenty of people tell me that there exist public repositories with wrong hashes in them, but when I asked them they never could come up with concrete examples in the wild.

I'm seriously curious about this, can you provide any clonable proof of concept repository with wrong hashes?

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

That second part of the fuller quote makes the first part irrelevant.

Git, sans GPG, does no validation of the given username and email - it is trivial to configure my laptop to stamp commits with hannob@ instead fragmede. All I need to do to frame hannob, then, is write access to a repo that they contribute to.

In the centralized world of github, that's a little bit more tricky, but at larger organizations where large groups (eg, all of eng) simply have write access to the repo(s), if git blame says hannob wrote the commit that stole passwords/money/etc, guess who's getting fired?

With GPG, I'm able to configure git so that commits that actually come from me have a GPG-validated signature. Snarkily, the blog post claims "no one" does this but I do. Given that this feature is known to be infrequently used, I'd believe it if git would accept commits with a bad signature.

I believe Git CAN check the validity of sha1 hashes (I read the source a few years ago and have a very tiny git commit) using git fsck, which I believe kernel.org does nightly. It just doesn't do so automatically with every commit or whatever. But you can set up a test in your server, I believe, if that's important to you, either watching the files, or checking pushes which I believe github does. So that's not the issue.

It's sha-1 collision attacks that are a theoretical issue.

My understanding of the currently known SHA-1 attack is that it requires binary data (hence PDF files for the example) and requires you to control both the original file and the subsequent file. So an attack would have to generate an apparently innocent file and a malicious file both of which have a binary block, insert the innocent file into the repo, and then somehow, most likely outside of a git push given mitigations like github's, replace that innocent file with the malicious file.

Now to your question, checking in the PDF files from the proof of the attack in git doesn't work, because git also adds header info. And generating the files requires ~ $100,000 dollars worth of ec2 time, or the equivalent, so nobody has gone through the trouble of generating files that allow this specifically to prove it for git. Bit it's definitely possible, and cheap enough for a criminal organization or a state agency to do. Just because someone hasn't done it for git specifically shouldn't mean that the attack isn't possible, just that security researchers don't have unlimited funds, and the existing proof, while not specific to git shows the issue generally applies.

Last I saw, the git mailing list was debating sha3-256 and BLAKE vs SHA-256. There's some indication that SHA-256 may get intel HW support, and that may be useful for speed with really really big git repos (like microsoft's apparently). SHA-256 doesn't have an attack on it that's known but unlike ShA3-256 (and I believe BLAKE since it's a stream cipher) SHA-256 is a block cipher, so it's not stateful. That means, while no known attack exists, theoretically if an attack existed you could corrupt a specific block in a similar manner to SHA-1. But SHA-256 has been much more extensively tested for issues while SHA3-256 is newer... it was created ostensibly as a backup in case the current known safe standard of crypto like SHA-256 is attackable.

There are some issues with SHA-256 being used in repos that have signed SHA-1 hashes already, in terms of mapping SHA-256 to SHA-1 hashes without borking the signing. Obviously if you change the underlying structure of signed stuff to store a new hash, it changes the hash.

My personal thought would be to implement SHA-256 and SHA3-256 as options simultaneously, as they are both NIST standards, make SHA-256 the standard so big repos can be as fast as possible.

I am not a crypto expert, or a git expert though, so if I'm wrong, please correct me. Being wrong means I get to learn stuff and that's great!

SHA2-256 has had hardware acceleration instructions on Intel since the Skylake series and on AMD since Ryzen; even ARM has has SHA2-256 acceleration for a while. Software support is the issue at this point.

How likely/easy would it be to add "know nothing" mirrors of these encrypted repositories? Say that I trust the keybase app (or something that speaks its protocols) possibly indefinitely, but maybe I'm not keen on a single cloud storage backend and want additional secure backup options. (Maybe I'm even unconvinced about the long term guarantee of keybase's storage space offerings due to possibly changing cost/business model factors, as others have pointed out here.)

It would be nice if I could have an encrypted copy in S3 or Dropbox or somewhere, that presumably maybe git couldn't directly make use of, and would be encrypted and those services couldn't touch either, but that the app could still push/pull changes to.

Certainly, I'd still have an unencrypted view of the contents in any local clones of the repository I may have in the case that I couldn't access keybase storage, but it still seems like there may be useful cases where an encrypted backup is somewhere else in the cloud as well, as a safe failover just in case.

I use [Pass](https://www.passwordstore.org/), a password manager, which uses GPG and Git, and I keep an encrypted copy of my Pass Git repo in Dropbox and have that repo copy setup as a remote in all of the local copies of my password repo. So, the contents of the local repos are encrypted, but in the encrypted copy all of the Git data is encrypted too.

Signing tags are not as affective as you'd think. refs are never actually signed, it's the objects they are pointing at that are signed. This opens up to interesting attacks where you can move refs around to previous vulnerable versions.

Yeah, we implemented this paper's proposal (their version has some bugs, gaps, and infinite loop issues) where I work to be able to have higher assurance on the validity of our source repositories.

First version in shell with a fairly robust test suite, and the next version in Rust. Originally started to do it in Rust, but libgit2 was sufficiently obtuse that we opted for getting to a complete, working thing first.

This looks fantastic! I have a couple of questions not answered in the FAQ though:

1. Is there (or will there be) any way to create an encrypted git repo shared between a few users that aren't part of a team? e.g. could I create a repo that belongs to eridius,chris and have us both access it?

2. Can I create a repo that belongs to a subteam?

And on a different note, I want to create a team but the name is currently taken by a user. The user has zero activity (no devices, no proofs, chain is completely empty, literally nothing). Is there any way to recover a name that's being squatted on?

> 1. Is there (or will there be) any way to create an encrypted git repo shared between a few users that aren't part of a team? e.g. could I create a repo that belongs to eridius,chris and have us both access it?

Yep, though it's undocumented and it won't show up in the GUI right now (maybe ever). You can just push/pull directly to repos like "keybase://private/u1,u2,u3/foo" and it will create it on the fly. But we warned, there's currently no way to delete those, and typos in the git URL can cause unintended repos to pop up.

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.

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.

Ah, so if I were to manually craft a commit in a text editor in the format:

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?

It doesn't seem to verify hashes of objects on checkout, but it does when receiving packfiles. So it's difficult to see how this could be an exploit unless the attacker has access to your local .git directory.

I’m sure there’s a law with someone’s name that states that. But just in case it hasn’t been claimed yet, I’m proposing that we call it the fuck you law. Because the next time someone comes to me to ask me to fix their trello to zappier to email to google sheets setup they use as a project management tool, I want to be able to say, “Fuck you and there’s a law that says so.”

No it doesn't. I have many of my git repos in Dropbox but I'm not using Dropbox for sharing. Having those in Dropbox means I get automatic backup and that they are available when I switch to a different computer, which I do, but not frequently. As only I use my Dropbox account, I'm aware of the potential sync problem, but it's never been a problem. I do run fsck & gc more frequently than most, but I probably don't need to.

EDIT: I should emphasize that this model is way more convenient than manually having to remember to push and pull all the time. Now push is only for publishing outside as it should be.

And even then, I never could break over the hurdle of setting up team repositories with safe credential management...like for any kind of collaboration. With this simple screen, you can grab 5 friends, make a repo in a minute, and all start working on it.

You can already do that with Gogs.. It's a single binary, uses git, supports accounts, 2 factor, etc.
https://gogs.io/
Really useful for small teams that don't want to use github or gitlab.

This looks sweet. I bounce between using Bitbucket or Dropbox for private repos depending on my needs. Bitbucket has lots of features but is a little annoying to set up a new project. Dropbox is really easy but doesn't always work well (e.g. git push ends up being effectively async). Your version of it looks to be just as easy as Dropbox, maybe even easier, but without any of the downsides. And it's encrypted!

Does it matter much? If I hose my repo (which I don't think is that easy, since I've been doing this for years and never had an issue) then I can delete it and clone a new one from my local copy. Especially when it's just me, and I'm only pushing to the repo from one machine at a time.

It can hose your local, too. And it can happen easier than you think--I've seen it happen because a laptop that pushed to Dropbox went to sleep mid-sync and a desktop synced after. Fighting the Dropbox API to unwind it is a huge pain.

git-remote-dropbox works as you would expect a Git remote to work; it's API-driven and actively discourages even syncing the remote repository down to your machine. I would so, so strongly suggest you switch to it if you want to use Dropbox as a store.

Bare-git-repo-on-KBFS is inadvisable for a similar reason, which is why I'm so excited to see what they're doing here.

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.

Yeah, keeping a local copy outside DB and pushing to a bare repo in DB is what I do. It didn't occur to me that one might work directly in a repository in DB. The hazards there, at least, are quite clear!

OK, so maybe we're using "local" for different things. Are you developing in your local copy of Dropbox, or are you cloning to a local directory using the Dropbox directory as a source (probably bare)? I assumed the former, which is what I meant by "local"; you can end up syncing multiple different instances of the repo and horking the contents of your .git directory (as well as cross-edited files, etc, that bleed changes onto multiple branches).

Both have the possibility of breaking because of concurrent or delayed syncs--like, which is actually HEAD?--but the latter is probably safer than the former. Or you can just use git-remote-dropbox and never have a problem.

If you always, always-always, develop on a single computer, Dropbox-as-normal-file-system can be fine. But if you have a desktop and a laptop, or multiple people partying on it, I get worried. :)

That explains the confusion, I'm talking about keeping a bare repository in Dropbox and cloning it to a non-Dropbox location on each computer where I work. It never occurred to me to keep the working copy itself on DB, that would be silly!

I expect that this could break the bare repository on DB if I ever pushed from two places simultaneously (where "simultaneously" could potentially encompass a period of hours or days if I pushed from an offline computer) but I should be able to repair it by recreating the bare repository.

Using something like git-remote-dropbox seems like a good idea. But at this point, I can just start using Keybase, hooray!

I don't think it's necessarily silly; it can be very useful in some scenarios.

I keep all my local working copies in a folder synced across several machines. I use Resilio Sync because it is better[1] than Dropbox for this purpose, but it's basically equivalent.

What this lets me do is stop working suddenly, at any moment (baby crying upstairs, or I lost track of time and have to bike to the office for a meeting) get up from my computer and move to another one (in another room in my house, or across town at my employer's office).

The code doesn't have to be in any finished state, needn't compile, I can literally be right in the middle of a line of code. As long as I've saved my work to disk, it will have synced before I reach the next computer, so I can sit down and resume work.

Before I had kids I didn't need this as much, so I just did git push/pull.

But then you have to do the work of pushing your half-finished junk to a different private repo, or rebasing to avoid polluting the git history with a bunch of crap commits just because you had to move, or not do that and just accept having a git history filled with crap.

Frankly I wish more of my work was capable of being distributed like this, but it's really only suitable for collections of plain files, which are amenable to being synced file-by-file. Luckily that includes almost all my programming work, however.

[1]: Resilio Sync is better than Dropbox for this because: it is much faster to sync than Dropbox, it supports symlinks so it doesn't corrupt your data when syncing folders containing them, and it syncs my data only among computers I control, not to any cloud service.

It took me about two seconds to create a new repository with Keybase and clone it to my computer, so I'm pretty impressed so far.

Thanks for the info about git-remote-dropbox and the potential failure modes of going without, even if they don't all apply to the way I've been doing things. It's still not ideal, so here's hoping Keybase makes it obsolete. If not, I'll keep git-remote-dropbox in mind.

What would I need to do to permit someone read-only, clear-text, non-public access to an encrypted repo? Can a combination of existing GIT / GitHub privileges and the Keybase solution help? If yes, and if you can add 2FA and we might be interested in becoming a customer.