Security concerns of "the first person who asks" for crate ownership transfer

[Marcono1234]

Currently https://crates.io/policies says:

To do this, you must publish a version with a message in the README communicating to crates.io support team that you consent to transfer the crate to the first person who asks for it:

I consent to the transfer of this crate to the first person who asks [email protected] for it.

(rust-lang/rfcs#3463 includes that as well)

How exactly does this "the first person who asks" work? If a crate has this in its README, does one really just have to write a mail to [email protected] to get access? Are there any checks done by the crates.io team, or can a completely anonymous person, who has never even contributed to the crate, take over the crate like this?

From a security perspective this sounds quite risky, especially considering how Cargo works and that it pulls the latest SemVer compatible version for dependencies, and therefore a potentially malicious version.

Should this policy maybe expanded to explicitly specify which checks will be done by the crates.io team to make sure the requester is somewhat trustworthy (e.g. must have contributed to the crate before)?
Or otherwise, should this section maybe be removed from the policy? Because an unmaintained crate might be better than one taken over by someone with malicious intents.

[Turbo87]

If a crate has this in its README, does one really just have to write a mail to [email protected] to get access?

yes

Are there any checks done by the crates.io team, or can a completely anonymous person, who has never even contributed to the crate, take over the crate like this?

there are currently no additional checks performed. the reason for that being that in all of the cases so far the crate in question was just a name squatted crate without any previous content or downloads.

should this section maybe be removed from the policy? Because an unmaintained crate might be better than one taken over by someone with malicious intents.

IMHO this is out of scope for the crates.io team to handle. crate owners can already add new maintainers to their crates without contacting the crates.io team and the same issues would apply in these cases. similarly, the crate owners can also add new people to their projects on GitHub without the GitHub team checking their credentials first.

[Marcono1234]

the reason for that being that in all of the cases so far the crate in question was just a name squatted crate without any previous content or downloads

There is for example https://crates.io/crates/wgpu-noboiler though, which does not seem to be name squatting.

crate owners can already add new maintainers to their crates without contacting the crates.io team and the same issues would apply in these cases. similarly, the crate owners can also add new people to their projects on GitHub without the GitHub team checking their credentials first

Yes you are completely right with that. My concern here is that the official crates.io documentation encourages this. And pretends this is a good / normal thing to do without mentioning any security aspects.

In my opinion either the policy should not mention this, or it should have an additional paragraph about the security consequences this can have, and the crates.io team should then have a (public?) checklist under which circumstances ownership will be transferred (e.g. name squatting, requester being a contributor, ...).

[Marcono1234]

@Turbo87, what do you think?

In addition to what I wrote above, if the decision is to keep this in the policy, maybe it would be better to require requests to be made here as GitHub issue (possibly with some issue template) to provide more transparency for such requests?

Also, would it be ok if I created an issue for this discussion here to make it easier to track this?

[Turbo87]

There is for example https://crates.io/crates/wgpu-noboiler though, which does not seem to be name squatting.

the only dependent crate for this one is also up for grabs. if the maintainer decides to give this name away then I don't see why the crates.io team would interfere with that decision.

the crates.io team should then have a (public?) checklist under which circumstances ownership will be transferred (e.g. name squatting, requester being a contributor, ...).

as I mentioned before, this is up to the owners of the crates. if an owner wants to transfer ownership to someone else then it is out of scope for our team to interfere with that.

My concern here is that the official crates.io documentation encourages this. And pretends this is a good / normal thing to do without mentioning any security aspects.

In my opinion either the policy should not mention this, or it should have an additional paragraph about the security consequences this can have

We mention this in the policy to reduce the amount of support emails we have to write and respond to, but I agree that an explanation of the security aspects of a name transfer might be a good idea. If you have a suggestion on how we could phrase this feel free to open a pull request for the corresponding policy page :)

[Marcono1234]

Have created #7361 for this