Closed carols10cents closed 5 years ago
Post I'm planning on submitting to users.rust-lang.org on Monday (I think this is better suited for users rather than internals, lmk if you feel differently... or maybe I should post to both for maximum visibility? 🤔)
Please let me know before Monday Nov 19 at 12pm ET if you have any suggestions for how to improve this!
Title: A verified email address will be required to publish to crates.io starting on 2019-02-28 Category: Announcements Body:
To comply with DMCA, we need a guaranteed way to contact publishers of content on crates.io. We've added the ability to verify your email address associated with your crates.io account, and we're going to require a verified email address to be able to cargo publish
to crates.io starting on 2019-02-28 (coinciding with the release of Rust 1.33.0).
Starting with stable Rust 1.32.0 that will be released on 2019-01-17, if you run cargo publish
using stable Rust and you have not verified an email address, the publish will work but you'll see a warning encouraging you to verify an email address before 2019-02-28. We'll warn for that whole release cycle.
Starting on that date, if you run cargo publish
with any Rust version and have not verified an email address, the publish won't work and you'll get an error that says you need to verify an email address.
You can verify or change your email at any time by logging in to crates.io, clicking on your icon/name in the upper right, choosing "Account Settings" from the menu, and going to the "User Email" section.
Some implementation details:
authors
metadata in the crate's Cargo.toml
. Cargo.toml
as well). cargo publish
will need to have their email address verified. And this is done! Whew!
Investigation results
Number of users potentially affected
As of 2018-10-29:
If we warn for a release cycle, we're likely to catch about 250 users and get them to verify their email address before it disrupts their workflow.
Ability to return a warning
Cargo does have the capability of displaying warnings from crates.io after a successful publish, however it's currently hardcoded to warnings about invalid categories and badges.
Proposed plan based on investigation results
I'd be happy to not get 250 emails complaining that we changed the publish workflow without warning, so I think we should warn for a release cycle.
For the purposes of this warning, potential future warnings, and potential warnings from alternate registries, we should add the ability to Cargo to display general warnings returned in a successful publish response.
Therefore, I propose the following plan:
Start publicizing this plan as soon as we agree on itDoneAdd general warning display capability to Cargo and get it into nightly in this release cycleDoneImplement the warning and hard error in crates.io, possibly with date checks so we don't have to remember to merge+deploy code on a particular dayDone