I just published my first crate on crates.io, so I added the rust bus!
I would be happy to be on the bus to help out as well (https://github.com/najamelan).
I would also like to share some ideas about formalizing the rust bus. I think we miss some formal policy as well as threat analysis of a malicious rust bus member action, and the required steps to undo the damage.
A policy should establish a clear protocol to follow before intervention, like:
- require at least 2 rust-bus members for any interaction representing the bus
- original owner should no longer be reachable/not responding for xxx time (shorter for urgencies like security/longer for general maintainance)
- rust-bus should never remove other owners from crates, …
- create a tracking issue first on the original repository allowing for the owner/community to react to the announcement of a possible rust-bus intervention, and only carry through if there is consensus…
- maybe require a moderation from the crates team before allowing rust-bus to carry out owner actions (given that it should happen only exceptionally)
A threat analysis should be make and written down:
- what happens if an administrator of the rust-bus org on github removes all other members?
- what does it involve to fix things
- how visible is it that rust-bus intervened?
- who gets notified if someone uses rust bus powers?
- any crates get rebuild automatically when deps change (could allow to introduce malicious code by modifying a dep)
Instrumentation could be added, maybe on crates like:
- could we have a contributor status on crates which cannot remove the original owner?
Once we establish that malicious actions can be detected and undone fast, I would be fine with trusting people by default. But we would need that analysis seriously I am convinced.