{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibypinpu2bpyggz6wudewwm27qjlmlwx5sxflzbbsnhl5mfpkfn6q",
    "uri": "at://did:plc:ivbknywyskln22er3nkssdhl/app.bsky.feed.post/3mkqzgkgu5lv2"
  },
  "path": "/t/pre-rfc-dns-domains-as-package-namespaces/24202?page=3#post_55",
  "publishedAt": "2026-05-01T01:26:57.000Z",
  "site": "https://internals.rust-lang.org",
  "tags": [
    "crates.io"
  ],
  "textContent": "mathstuf:\n\n> How would this work with crate ownership? (This may very well be addressed in epage's prior collection of this topic.) If I add another developer as a maintainer (uploader) of the package, do I need to somehow give access to my domain?What if I later want to no longer maintainer? Do I have to transfer domain ownership too? What if I still have crates I'm continuing to maintain? Or do I have to somehow communicate with all consuming projects about the new domain?\n\nI believe your questions are addressed in the first post.\n\nIn the original proposal:\n\n  * Crate ownership semantics are unchanged. The existing permissions logic crates.io is what determines who can publish updates to a crate.\n  * If you transfer ownership of your crate then the new owner will be able to publish updates to it.\n  * Crates can't be renamed, so if you want to transfer ownership then you can either:\n    * add them as an owner to the existing crate (under the original namespace), or\n    * they can publish a new crate under a namespace they control, and users would have to update their dependencies to reference the new name.\n  * Granting permission to publish a updates to a crate does not require you to transfer ownership of the domain.\n\n\n\nIn the thread there were some discussions of possible adjustments to make the access control stricter, including:\n\n  * Requiring domain control be verified for each published update.\n    * This would prevent publishing updates to crates under a domain that lapsed.\n  * Having crates.io keep track of domain ownership.\n    * If a domain lapses and someone else leases it then they wouldn't be able to publish new crates without asking the crates.io administrators for help.\n\n\n\n> Feels like a wonderful gap for social engineering to crack in and get a few users to use a trojaned crate.\n\nThis proposal does not add new vectors for social engineering. Some of the proposals remove vectors by requiring additional authorization when creating or updating a namespaced package.",
  "title": "[Pre-RFC] DNS domains as package namespaces"
}