Child Thread: Survey of organizational ownership designs for Cargo and Crates.io

tools and infrastructure cargo
1

For background context and links to other threads, see Survey of organizational ownership and registry namespace designs for Cargo and Crates.io. This thread assumes that one has been read.

This thread is for summarizing approaches for improving organizational ownership without namespaces. Other general approaches include:

Debating which proposal Cargo and Crates.io should go with is off-topic for this thread. Please create your own thread.

Prior art

Those relevant for this thread

Nuget prefix reservation

Organizations can register package name prefixes that give them exclusive access to publishing under. These packages get a badge. Badges are permanent.

Existing packages at time of prefix registration are still allowed to exist and don't prevent registration of the prefix but they do not get the reserved prefix badge.

Only one owner of the prefix needs to be an owner of a package to get the badge. Package owners who don't own the prefix cannot remove owners that do. An owner of the prefix must always be the owner of the package to ensure the badge is permanent.

Sub-prefixes can be carved out and transferred.

An owner can mark a prefix as public, allowing anyone to publish to it.

Requesting a prefix is done by emailing nuget.org maintainers who also handle disputes. Unclear what verification is done.

Compared to use cases:

  • Squatting and typo squatting is reduced to the prefix portion
  • Not friendly to renames or prefix transfers

Compared to requirements:

  • Could break up existing culture of publishing packages under other's prefixes
  • Potential for abuse with people reserving prefixes used by other projects
  • Verification process is pushed onto the crates.io team

References:

Potential solutions

Publish-owners (no-op)

Today, you can get a sense for the organization behind a package by its publish owner, e.g.

cargo-supply-chain helps to raise visibility of the publish-owners in your dependency tree.

Ownership may change and users may not be aware of it.

Compared to use cases:

  • Helps with understanding official ownership but not other use cases
    • No verification
    • User must verify organization behind owner
    • User won't be informed of ownership transfers'
    • Trust is being built on implementation details of an organization's processes which can change over time

Compared to requirements:

Future possibilities

  • Adding a display name though that runs into issues with ensuring it is representative and not obscuring (e.g. a malicious actor changing their display name to "Google")
  • Being able to elevate the organizational owner as the one that matters among all of the owners
  • Prominently showing the owner in the UX for crates.io and cargo

References:

Brand badge

An organization tag was mentioned in passing in the 2014 crates.io package policy document and I cannot find any follow up discussions with more details, so we're going to make suppositions. We are renaming this to "brand badge" as it feels like it better conveys the intent.

A package may opt-in to one specific brand badge. The brand is associated with a domain and the domain must recognize the packages claiming to be part of the brand through a DNS TXT record.

Verified badges will be marked on the crates.io page and the brand may be displayed along with the package name in the UX for crates.io and cargo.

One option would be to collect a fee for corporate brands as a way to generate a modest amount of revenue to support crates.io's governance and development.

A package could specify its brand via package.brand but runs into the mutable metadata issue. It may be better for this to be a property stored in a registry database and changed in the registry UX and possibly through a cargo subcommand.

If the brand is not the domain itself but a display name associated with it, this can run into issues with malicious actors spoofing other brands.

Open questions:

  • Would users want to be able to track owners in git history (through tracking in Cargo.lock)?
  • Would users want to pin owners?
    • cargo add regex --owner rust-lang
    • regex = { version = "1", owner = "rust-lang" }

Compared to use cases:

  • Helps with understanding official ownership but not other use cases

Compared to requirements:

  • While this requires a domain which can be a barrier, it is offset by just being for a brand and if you are developing your brand, you likely have a domain

References:

Child Thread: Survey of registry namespace designs for Cargo and Crates.io
Child Thread: Survey of registry namespace designs for Cargo and Crates.io
2

For https://lib.rs I wanted to figure out grouping of packages like "official Rust package", or "tokio crate", or sort packages like serde-* into officially belonging to a project vs 3rd-party crates that are for the project.

Something explicit is definitely needed. Heuristics aren't sufficient - there are soo many edge cases.

  • there can be some primary package foo owned by owners A, B, and C, and packages foo-something owned by A only, or B+C, or A and other owners. Figuring out who is the real owner of the "namespace" is very tricky. Sometimes foo and foo-quuz may have the same owner, but the owner considers foo-quuz a side project or a reserved name, not really belonging to the foo project. Some crates have a GitHub org account, but not added to all of the relevant packages. Sometimes the non-user account is just a bot that's not a real project owner.

  • even crates sharing a monorepo don't always belong to the same project! Even after verifying the crates really exist in the repository from the URL in the package, and aren't forks or fakes, they can turn out to be helper utilities (for CI, precompiled data) or crates maintained for the project by the project members, but intended to be usable outside of it (like a CLI arguments parser).

  • "Rust official" also doesn't exist. There are many members of the Rust org who publish their own packages, not as Rust representatives. There's huge legacy of alexcrichton's packages. There are packages technically owned by rust-lang-owner, which greatly vary in their importance (from key crates to forgotten experiments), release process, de-facto owners/maintainers.

6 Likes
Child Thread: Survey of registry namespace designs for Cargo and Crates.io
3

Some of this touches on that a package can be owned by an organization, the intent also matters. For the Rust Project, we break them down into Intentional, Internal, and Experiments (source). I wonder if something is needed for that.

4

Some of this post is relevant to this thread

5

Well, so. I probably hit a lot of cases in this, so @epage happy to be interviewed in the implementation.

Independent of namespacing implementation, we have:

  • A company name (company names are trademark like) that has a community-wide nickname (ferrous-systems, ferrous)
  • A trademark for a bigger product that we want to keep "closed" (ferrocene), we do not want someone to publish under that name.
  • We maintain some projects that we are responsible for, but where the name is "open" (e.g. "defmt", where a third party example publishing "defmt-my_funny_testsuite" is totally encouraged). Any negative stuff happening on that front would probably violate crates.io policy and does not need any special care.

So, as an org, we at least have a 1-N relationship to namespaces.

Edit: In case 3), there is actually a reason to have that as a case - community protection. You don't want an open vendor namespace to be "rug-pulled". But that's more policy than implementation.

1 Like
Survey of organizational ownership and registry namespace designs for Cargo and Crates.io