Bus Factor +1 for crates (now dead)

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.

2 Likes

ps: more concretely. Maybe we could create one repository in the github account for rust bus, where we could draft a protocol, make a readme that explains formally what rust bus is, and have issues to discuss things. All members could follow the issues on the bus and if an intervention is required, it could first be discussed there, so nobody goes solo.

Thanks for your detailed feedback. We will take this into account if we plan on formulating a detailed proposal.

This is a good idea, however since rust bus will be often used at "emergency time" when you need to publish a new release (or any other task) urgently - waiting for another person to respond might not work well.

We won't be removing any member from a crate/organisation. If it is a security issue, then the crates.io team will be doing the needful.

Does rust-bus have a presence on GitLab as well, or just GitHub?

Just github, because crates.io only supports github accounts.

Only just became aware of this project because of recent responses. I think this project should be mentioned somewhere prominent on crates.io to ensure it isn't forgotten once discussion calms down.

E.g. one of the pages explaining how to upload crates perhaps?

1 Like

Is the project still active? I have published several crates for which I sent an ownership invite to rust-bus, which was never followed up...

crates-io doesn't send e-mails when someone is invited, so I have to periodically check manually.

It is a lot of trust, I wouldn't do it.

Indirect links (URL Forwarding)

I would prefer crates.io to be an indirect link service to a crate repository (URL forwarding service for a crate repository).

At crates.io, the bus-factor team can then change the URL forward to a newly created fork of the original author's repository.

That avoids the possibility of someone breaking trust.

For the crates.io to be an indirect link (URL forwarding) service for a crate, the service can look at the user-agent. If it fx is a browser, show web page, otherwise redirect.

It would be a very good idea to have the ability to force crates.io to return the web page or force crates.io to return the repo link. I would suggest using a cookie to do that.

It can also be the HTTP method, fx GET (browser default) for the crate's web page, and tools use POST for URL forwarding.

Idea is from https://labix.org/gopkg.in
Read the Introduction.

Is this organization still active?

I'd like to join. I maintain config-rs and shiplift (I took over, I am not the author of either) and I would like to see some other crates to be more maintained (e.g. futures-codec right now, as it is a dependency of shiplift and but its dependencies are rather outdated).

3 Likes

Almost three years later I conclude: The Rust Bus is dead.

Not enough drivers.

No longer active.

9 Likes

How many crates are already successfully recovered from abandonment by the Bus Factor +1 project?

3 Likes