1.28.2 release plan

[djc]

We released 1.28.1 (release plan) on an urgent schedule to address the main pain points from 1.28.0. We expect we will release 1.28.2 soon to address more feedback. Some things left out of 1.28.1:

• Generate warnings for implicit installations that may become explicit only in the future
• There should be a setting (in addition to an environment variable) to control whether implict installation is allowed Add set auto-install disable #4254
• Recommended toolchain install command line isn't exactly right #4212
• rust-toolchain.toml is not used for rustup toolchain install #4216
• 1.28.0 does not accept components separated by spaces #4220
• Fails to add component on Windows #4232
• Nushell environment script (env.nu) is using the wrong string #4242
• Make downgrading via the archives work #1158

[foresterre]

Thanks for the quick responses and hard work!

[gmorenz]

I'm a bit hesitant to weigh in here as a relative outsider, but

Generate warnings for implicit installations that may become explicit only in the future

It feels like there should be a decision if this is the right path forwards at all, before doing this and effectively asking the entire ecosystem to do work to prepare for this future decision. Even if this is the path going forwards, it doesn't feel like something that should be in a patch release at all. It's not a bugfix, and there's no reason to rush the rollout of the warnings and subsequent change (that I see).

---

I'm also against the change as currently proposed regardless of release timeline. I'm just a random user, my opinion should be given no special weight, but I thought it worthwhile to write down and share:

I think these two comments¹ on the main thread do a reasonably good job of capturing the friction this will add to regular every day users of rust's workflow.

I think it's also important to consider that this will "bitrot" a lot of documentation that tells people how to build projects, and doesn't tell them that they need to tell rustup to install the toolchain because when the documentation was written that was implicit. Documentation is relatively unlikely to be updated, since unlike CIs it doesn't tell you it's broken. Outdated information in it hits newcomers to a project particularly hard, leaving a bad first impression.

I think this change will result in a semi-justifiable backlash about rust being "unstable". Yes, it's not rust itself, but it's a backwards incompatible change being made in the core tooling.

I suspect that most of the benefit of this change can be achieved with less invasive changes. For instance

• An environment variable and config settings to disable the implicit behavior are great (thank you for adding them :)). This resolves the issue for a certain category of user who is particularly concerned about implicit behavior.
• Having rustup as invoked by the cargo wrapper, provided settings don't override the behavior, keep the implicit behavior. While having other commands not². This makes sense, at least to me, because cargo as a package manager is generally expected to implicitly download dependencies, while rustc and friends are not. This probably resolves the issue for most of the "ricing" use cases where someone is implicitly calling rustc --version. Meanwhile it avoids breaking most workflows.
• Restricting implicit toolchain updates to official toolchains³, this almost fully mitigates the security concerns while impacting almost no one in a negative way.
• Releasing the change under a https://sh2.rustup.rs⁴. Potentially this wouldn't even install a different binary, it would just set a different default configuration. This would I think fully mitigate the backwards compatibility concerns.

Importantly all of these mitigations would change what warning needs to be given to who, and what actions need to be taken by the people who receive the warning. So if any of them are being considered, it seems like that consideration should happen before asking the ecosystem to start making changes via warnings.

PS. As always I want to extend my thanks to everyone donating their time to make this ecosystem run. I may disagree with the occasional decision, but I have no doubt they are being made with the best intentions and overall make things much better.

Footnotes

1. https://github.com/rust-lang/rustup/issues/4211#issuecomment-2695957173 and https://github.com/rust-lang/rustup/issues/4211#issuecomment-2697620100 ↩ ↩²

2. Credit for idea: https://github.com/rust-lang/rustup/issues/3635#issuecomment-2298761918 ↩

3. Credit to the first comment I link in ¹ ↩

4. Credit https://github.com/rust-lang/rustup/issues/4211#issuecomment-2695436922 ↩

[mitsuhiko]

Restricting implicit toolchain updates to official toolchains3, this almost fully mitigates the security concerns while impacting almost no one in a negative way.

FWIW cargo itself is happily executing untrusted rustc binaries that can come straight from the repository, so rustup using the toolchain is not even the highest risk thing here. If there is a desire to fix that, then it would make sense to investigate that together with cargo.

[rami3l]

@gmorenz There is an additional thing I'd like to address by restricting implicit toolchain installation: it happens so frequently that you might hit #988 from time to time, and to resolve that problem we'll need to implement a lock.

Regardless of the actual locking scheme that will be implemented, it will definitely be a mutex for writes, so it is undesirable that even cargo --version might block for an unexpectedly long period of time on getting the write lock when trying to implicitly install the toolchain. Thus, instead of letting it block extensively, it's better to halt immediately so that the user can take action accordingly.

TLDR: We need to make at least most rustup commands safe to run without potentially blocking each other. However the 1.28.0 breakage has made me rethink about this: it is highly probable that one wouldn't want to care about locking in CI (where "the user can take action accordingly" doesn't hold, since there's no such user), so it might mean we need to maintain two sets of behaviors for different scenarios.

OTOH this doesn't mean #988 doesn't occur in CI: we have #4232 for instance.

[foresterre]

Regardless of the actual locking scheme that will be implemented, it will definitely be a mutex for writes, so it is undesirable that even cargo --version might block for an unexpectedly long period of time on getting the write lock when trying to implicitly install the toolchain. Thus, instead of letting it block extensively, it's better to halt immediately so that the user can take action accordingly.

I'm not so certain that it's better to halt immediately over blocking extensively.

I would expect that for most users the immediate action would be to either try again (which is not so different from waiting for the lock I think), or write a script which does just that? I suspect this is also the same for CI.

For me, the real tradeoff is not so much the blocking extensively vs. not blocking, but the backwards compatibility promise, and the out of the box easy of use.

An alternative option (but similar to the environment variable suggested above) could be to add a new install subcommand (or flag) which does implement the new behaviour; then it would be an opt in.

[rami3l]

I would expect that for most users the immediate action would be to either try again

@foresterre Thanks for your input. However, as you have already mentioned, many rustup invocations are already implicit (e.g. by your IDE), so in that case you won’t directly understand that it’s rustup blocking you, nor will you have the direct control to try it again.

I’m also doubt whether Cabal’s v2-install and friends are a reasonable choice for Rustup. Without a clear way forward, I’m currently inclined to keeping both behaviors under a flag like we currently do.

[ChrisDenton]

Can I yet again suggest postponing adding warnings for potential future changes?

There are already plenty of fixes and improvements included in 1.28.2 that I don't think we should block on figuring out our future plans. And I do think we need a plan for what we will/won't change before we add warnings as well as some way for users to opt-in to the new behaviour before it's stable.

[djc]

Works for me.

[rami3l]

@ChrisDenton Yup, although I want to land #4230 as well if possible...

[djc]

I would suggest that maybe we can get an issue written up with the costs/benefits of the intended new behavior change which we can then advertise in the 1.28.2 release announcement for a public feedback period, kind of RFC-like?

Maybe even as an actual RFC in the rfcs repo.

[ChrisDenton]

I think it is a good idea to focus on gathering feedback. I've created an issue for discussing this that lays out the background information #4264.