Hacker News Reader

Comment by robin_reala | Hacker News Reader

What reasonable measures could have been put in place that would both avoid this bus factor and balance the other way against the risk of a project running into problems from split management?

View on HN

First off, I'm surprised an open project has such a high bus factor. There should always be a contingency plan.

The IRC channel could have easily been protected if a second or even third trusted member of the team was given admin privileges and/or access to bots. The domain and github accounts are tricky because of ownership and financial payments.

The right way to do this would be to form an organization (non profit, etc) and register all the domains and accounts to that entity. Then delegate access to one or more trusted members with the founder as the head.

And finally, let this be a lesson to open developers. If you want to participate in a large open project, check the bus factor and proceed with caution.

The Software Freedom Conservancy might be able to help: https://sfconservancy.org/

Debian has key distribution system. Every critical password/key/etc. is divided into `n` parts, where `m` parts (obviously m < n) can assemble the data back.

These are used primarily for repository private keys, revocation keys and like.

In this scenario, in case of emergency, secondary level officials can assemble the key (or secret) if something unfortunate occurs to the top level management.

For Debian FTP Archive secret keys, Debian uses 3 out of 5 arrangement, as can be seen in https://ftp-master.debian.org/keys.html. See SSSS holders section.

This is not a tech problem waiting for a tech solution; it's a people problem. Project managers/admins/maintainers need to be able to share power for long-term survival (exceptions are rare). This is step one and for most projects there are no ways around that.

If that's the case, then we can talk about tech solutions, but for the most part that's sharing account data for SPOF-y things like domain and hosting contracts.

Perhaps timelock[1] variants could be implemented if a usable option comes up. The idea being that if access or activity is dormant for a period of time t, then at t+1 secondary keys can be used. This presumes that organizations wishes to maintain a "single focal point" and not simply share the access amongst several individuals.

Timelocked secondary keys/credentials could be used as a fail safe. If one wants to really design safety into the system, ensure each admin-level key is revokable, and then wait for t duration.

[1] https://en.bitcoin.it/wiki/Timelock

For starters having more than one person with admin / owner level of access. At least three is better but even two people reduces these risks and significantly lowers bus factor.

Is this the famous three is two, two is one and one is none?

What most companies have is access controlled by an organizational superuser team.

At large companies, this means that each team has full or near-full control over their "jurisdiction." IT has full control over LDAP accounts, and since they're a team, one person going AWOL won't affect the org as a whole. There are also infra teams that control domain routing and hosting providers.

The way we used to do it in our bit of BT was for passwords to be limited and to be written down put in an envelope and stored in the fire safe.

Perhaps core infrastructure passwords for a project could be placed in a dead-man's-switch escrow service, where they will only be released to a larger core team if NONE of the (potentially multiple) project leaders with those passwords check in for a certain period. Current blockchains/crypto don't permit this without a trusted third party escrow service, though, AFAIK.

Register as a (non-profit) corporation, appoint a board and keep all important credentials in escrow. Assign job titles and job specifications to all key personnel; if you don't know exactly who is responsible for what, you can't make contingency and continuity plans. Reject all pull requests that aren't comprehensively documented.

It sounds like a lot of work, but it has a tremendous RoI. The advantages of corporate personhood more than outweigh the administrative burden for a serious open-source project. The issues affecting Void are practically moot if accounts and domains are owned by a corporate person rather than a natural person.

It's obviously overkill for a personal side-project, but I'd consider it essential once you're starting to worry about your bus factor. If no-one involved in your project wants to deal with this admin, find someone who does. There are a lot of non-technical people who would still like to contribute to the free software movement.

> Register as a (non-profit) corporation

This can be expensive and time-consuming in the US, at least.

I see no reason why a legal entity is needed here. Just set it up, keep all your credentials in a place that's accessible in a contingency, and move on with life.

I feel like this is more of a human problem than a tech problem. Tools like github should allow org owners to declare a "will" of sorts when they go missing, including conditions to meet, who has access and contact methods. But maybe that puts an unacceptable burden on services like this.

You first say it's a human problem rather than tech then go on to suggest solving it with tech!

Solving the human problem with humans - trust someone else with the keys if you have a collaborative project

Writing a document explaining how a customer service rep at some company should go about transferring ownership of your account is not solving the problem with tech. I listed things that the document should include that a human can execute, not an automated system.

I think it was on my part that jumped to code when I read “conditions to meet” there then

My apologies!

I think the primary measure is simply "think about it in advance". The major requirement is just to make sure that multiple people have the necessary admin accesses; this is seldom technically tricky. You just need to take an afternoon to list up all the resources your project has and for each (a) who has access and (b) who has permissions to change the access rights. Then review it occasionally to make sure the list still has enough active members on it to be safe. It's also a useful document to have around so that when somebody says "who do I need to talk to to get access to our foo servers" you know the answer.

This is a little like backups. If you don’t test restore, then the value of your backups is low.

If the project has bandwidth you should consider doing fire drills for your important scenarios. Push a major version, upgrade infrastructure, etc

Reply on news.ycombinator.com