cargo publish should be opt-in

[jmaargh]

Publishing, whether to crates.io or elsewhere, should be opt-in rather by on-by-default. Although rare, people do sometimes publish accidentally. Given that the default is currently to publish to crates.io publicly, this is potentially dangerous for using cargo in a corporate closed-source environment. My guess is that even most always-intended-to-be-open-source projects would rather keep things private until they're ready for some sort of release.

I see several options for making this work:

1. Have cargo new add publish = false or publish = [] or equivalent in the default Cargo.toml. This is probably the most minor change and I can't imagine this will break any existing uses.

2. Change the behaviour so that publish = true in Cargo.toml is required for cargo publish to work, with an error message explaining this. This might break workflow for some existing projects, but it would be a very easy fix.

3. Change the behaviour of cargo publish so that if there is no publish = True in Cargo.toml it interactively asks whether you're sure. Possibly with a -y/--yes option (a la apt install) to automatically say "yes".

Personally, I'd prefer both 1 and 2. I'd be happy to make a PR if people like this idea.

Originally raised as an idea on #6123, but was decided it belonged as a separate issue.

---

Proposal as per this comment is to change the default Cargo.toml generated by cargo new to include publish = false with a comment pointing towards documentation about publishing.

A separate issue will be opened to cover breaking changes to behaviour to be targeted at an edition boundary.

[withoutboats]

My initial inclination is against doing something like this, but I could be convinced.

There are a few barriers already against accidentally publishing:

1. The cargo publish command has no other purpose, and none of our other major commands are similar, making users less likely to accidentally run cargo publish when they meant to run something else.
2. The publication will fail if you aren't logged in, making it less likely for you to successfully publish something when you are new to Rust & haven't yet learned what cargo publish is for. That is, the first time you publish you have to actively try to by creating a crates.io account, so we avoid the problem of people running commands without understanding them.
3. The crate created by cargo new will be rejected by crates.io because it lacks a license and description field. You have to have set both of those up before you can publish.
4. cargo publish fails if your crate doesn't build or if your VCS repository is dirty.
5. If you're publishing a subsequent version of a crate, cargo publish will fail if you haven't updated the version number to the new version.

My own experience of publishing is that I almost always run afoul of one of the existing checks when I go to publish - usually I haven't set a license or description field.

Often the code you don't want to publish is a project you intend to publish someday (and you may have already published a previous version of it). Its perfectly possible to set the publish bit and then run cargo publish by mistake later. That is, this only prevents an accidental publish of a completely new crate, and only once all of the other roadblocks mentioned earlier have been hurdled by the user.

---

More succinctly, the only interface that will prevent people from accidentally publishing is to disallow publishing entirely. I don't think accidental publishing happens often enough right now that there need to be more roadblocks than there already are.

[jmaargh]

I agree that accidentally publishing is probably a niche issue, but I don't see how yours are arguments against this proposal, so much as they are arguments that in your experience it's unnecessary.

One way to think about it is this: if we're going to have a publish flag, then it should default to the "safe" state of false (you never lose anything -- except a couple of seconds -- by not publishing when you meant to). If the publish flag is so unnecessary, then it should be removed altogether. Right now, there is a flag whose only purpose is to save you from yourself that defaults to the "unsafe" option.

As for the other barriers, I think they should all remain, but none of them are as explicit as "I don't want this published". For example, you might choose to not set a license, or not log in, simply because you don't want to publish. But in a year's time, you're unlikely to remember that. The advantage of the publish flag is that the intentionality is explicit.

[alexcrichton]

cc @rust-lang/cargo, others likely have thoughts on this as well!

[joshtriplett]

My initial feeling is -0 (weakly opposed). I don't feel strongly about this, it just feels like a bit of an unnecessary stumbling block in a new project. I can absolutely understand the desire to make sure people don't publish accidentally, however.

[ralfbiedert]

We have the same problem, a package we would like to prevent from being accidentally published.

However, couldn't we do it like npm does it, providing a private flag instead?

I think I want to have things publishable by default (less friction, expected behavior for open source projects) but would like to have the option to opt out for commercial ones.

[sfackler]

@ralfbiedert that's the current behavior via the [package] publish = false setting.

[bestia-dev]

There are actions that are reversible and actions that are irreversible.
cargo publish
is terribly easy to write, run and misunderstand.
Later is not possible to delete a published crate. That is very irreversible !
That is disproportional !
A simple easy security measure should be enought: require the name of the crate to publish:
cargo publish --crate my_crate_name
That is more complicated to write but is proportional to the gravity of the action.

Another idea is to allow 5 minutes staging time to delete the published crate on crates.io.
In that time it should not be visible to others.
And maybe a command `cargo publish --force --crate my_crate_name'
for the people that need it published pronto.

[bestia-dev]

Publishing a new crate or a new stable version of a crate is pretty rare.
And it needs a lot of preparation and thinking through.
An unintentional publish can have very grave consequences.
Because of that the command could be a little more engaging for the developer.
For example requiring this arguments:
cargo publish --crate my_crate_name --vers 1.0.0. --reg crate-io
This protects the developer to not publish unintentionally the wrong crate or the wrong version to the wrong registry.
Having dangerous default values can lead to secrets or private code been published publicly.
In a split second, there are robots that will make a copy of that code.
And in a few minutes, they will exploit a password or a secret token.
These are very bad consequences.
We can easily prevent that from happening.

[jmaargh]

@LucianBuzzo The point that people might accidentally (or lazily) have secrets in code they don't intend to publish is a good point I hadn't thought of.

Personally, I find the current behaviour at odds with the usual approach to safety in Rust. Publishing code (especially to crates.io, which has no easy removal mechanism) is an "unsafe" action, therefore it should require some explicit opt-in on the part of a human.

[mcobzarenco]

Another idea is to allow 5 minutes staging time to delete the published crate on crates.io.

That's almost implemented via rustc compilation times -- there's usually plenty of time after typing cargo publish to change your mind :-)

cargo publish --crate my_crate_name

The only time I ran cargo publish by mistake is pressing arrow up and rerunning the command from shell history -- this would not guard against that.

I tend to (weakly) agree with the opinions already expressed that the current behaviour is not too bad -- there are many "irreversible" commands one can run (e.g.rm -rf) -- given that cargo publish doesn't have any other uses, the status quo seem appropriate.

From the 3 solutions proposed by the OP, 1 seems particularly unappealing as the default should be open source, not a corporate environment (writing this as someone who mostly uses Rust in a closed source corporate env).

[bestia-dev]

Sorry, you didn't mention my last proposal - all args mandatory:
cargo publish --crate my_crate_name --vers 1.0.0. --reg crate-io
That solves all current safety/security/clumsiness issues:

1. Cannot type 'cargo publish' by mistake and expect a guide/help for the utility. Instead it goes for the kill.
2. Cannot inadvertently call 'cargo publish' in the wrong project.
3. Cannot mistakenly publish the wrong version.
4. Cannot forget to explicitly choose the crate database

I suppose developers use the bash history for all the frequent commands. Also for this.