Verified organization on

In package policies @steveklabnik wrote:

One situation in which a namespace could be useful is when an organization releases a number of related packages. We plan on expanding the ‘tags’ feature to indicate when multiple crates come from one organization. Details about this plan will come at a later time

Are there any updates today?

I'm running a few projects in the ASF (Apache Software Foundation), like OpenDAL -

It creates a requirement for trademark policies that we'd find a way to declare it's a crate endorsed by a ASF Project Management Commitee (PMC). We can do it in Maven since the groupId is verified. We can do it in NPM with verified scopes. But for, it seems only rename the package to apache-opendal helps a bit, while anyone can create a crate with this name, there lacks the significant organization verification part.

So, I wonder if the situation of changes and there is anything we can leverage.


Not exactly you're looking for, but RFC 3242: Packages as (optional) namespaces is a path forward.

1 Like

You could also mention it in the readme with a link to the Apache website as proof.

This is of course a good supplyment, but not for users directly hitting the crates from other sources.

For myself, I would discourage "Packages as (optional) namespaces" as a solution to this. I recommend against viewing that as a general purpose namespacing solution. Instead, it is an API design solution (partially open namespaces).

For example, one of the topics that came up in that RFC is about moving things in and out is a semver breakage (unless you use the semver trick). A proper namespacing solution would need to take that into account.

4 Likes knows crate owners' github org team memberships. It could highlight when a crate owner/team belongs to one of notable github orgs.

1 Like

What makes a org notable? Who decides and what are the criteria?

I think this has the potential to be super complicated and contentious.

Could be verified domains which allows punting on a lot of sticky points but is pay-to-play.

iirc domain verification was talked about in

Team owners might be sufficient attribution for the ASF: e.g. make github:apache:pmc an owner on endorsed crates. That this team is tied to a verified GitHub organization serves as a verifiable trace of endorsement — only members of a team are allowed to add a team as owner, so it can't be spoofed by some random crate inviting the PMC as owner — even if it isn't directly displayed in the cratesio interface.

Obvious disclaimer: I am not a lawyer nor associated with the ASF. Ask them.


I'm not a fan of pay-to-play solutions. And it is not that hard to get a typosquat domain name as I understand it, so it doesn't actually help that much anyway.

And if anyone with a domain name can say that they have a verified organisation that doesn't really add much. If you need more than just a domain name for automatic verification you are back to sticky points again.

I have a domain (for email and static website, that I rarely update). Does that mean I'm verified now?

Unfortunately this is a very hard problem, as evidenced by Twitter's controversial history with verified badges, long before they were reduced to the $8 farce.

The most problematic aspect is that to some people a "verified" badge will also imply endorsement or trust. There are military contractors, spy agencies, and cryptocurrency companies using Rust that may be controversial to some people, and it may not be a good look for crates-io to give them some positive mark.

OTOH verification of just a domain name sets the verification bar very low, where even spammers could find some domain to verify. There will be usual problems with domains, such as homoglyph attacks, typosquatting, subdomains with XSS-vulnerable software, and possibly problem of legitimate orgs using not their most canonical domain (e.g. instead of