`rustup up` should not downgrade toolchains

[neolib]

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

rustup up does not validate remote version against local version.

I found out this because the fastest mirror (RUSTUP_DIST_SERVER) was temporarily down and I switched to another one, which unfortunately had an outdated version 1.96.

When I ran rustup up, it unconditionally removed my local version 1.97.1 and installed the old versin 1.96.

Steps

N/A

Possible Solution(s)

No response

Notes

No response

Rustup version

rustup 1.29.0 (28d1352db 2026-03-05)

Installed toolchains

Default host: i686-pc-windows-gnu
rustup home:  C:\Programs\rust\rustup

installed toolchains
--------------------
stable-i686-pc-windows-gnu (active, default)
stable-x86_64-pc-windows-gnu

active toolchain
----------------
name: stable-i686-pc-windows-gnu
active because: it's the default toolchain
installed targets:
  i686-pc-windows-gnu

OS version

Windows 11 25H2 version 10.0.26200.8973

[rami3l]

@neolib Thanks for reporting!

Considering the fact that RUSTUP_DIST_SERVER is intended for alternate release servers and that you are switching from one stable manifest to another, IMHO this is the existing behavior (since the stable channel manifest is a "moving target" and is supposed to always point to the tip).

[djc]

IMHO this is the existing behavior (since the stable channel manifest is a "moving target" and is supposed to always point to the tip)

I'm not sure what you meant to express by this, but it sounds a little dismissive?

It seems reasonable to me that rustup up should refuse to downgrade by default, do you agree?

[rami3l]

It seems reasonable to me that rustup up should refuse to downgrade by default, do you agree?

@djc Yes, I definitely agree with that. Of course if this happens on the official release server then it'd be reasonable to refuse downgrading at least by default, unless is it used as a backdoor for yanking newer versions (does this thing even exist?).

My question is: in the past we have largely relied on the trust of the release server. Now how confident should we be in assuming that different release versions on different release servers are always comparable (e.g. conventionally we can probably compare by standard semver order)?

Although I'm sure as a fellow Chinese that in @neolib's case they are at least intended to have the same contents.

When the above question is addressed I'd be glad to add a new flag à la jj --allow-backwards to allow downgrading only when explicitly instructed.

[djc]

When the above question is addressed I'd be glad to add a new flag à la jj --allow-backwards to allow downgrading only when explicitly instructed.

Yeah, I was thinking maybe with --force.