`rustup update` 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.

[rami3l]

So I've done an analysis of the current analysis, and it seems that this feature has already been half implemented:

• rustup install has a flag allow_downgrade and defaults to false.
• rustup update issues update(.., UpdateOpts { .., UpdateOpts::default() }, ..), where allow_downgrade is already false.

The above flag only influences the following comparison:

rustup/src/dist/mod.rs

Lines 979 to 998 in 531b744

	// In case there is no allow-downgrade option set
	// we never want to backtrack further back than the nightly that's already installed.
	//
	// If no nightly is installed, it makes no sense to backtrack beyond the first ever manifest,
	// which is 2014-12-20 according to
	// https://static.rust-lang.org/cargo-dist/index.html.
	//
	// We could arguably use the date of the first rustup release here, but that would break a
	// bunch of the tests, which (inexplicably) use 2015-01-01 as their manifest dates.
	let first_manifest = date_from_manifest_date("2014-12-20").unwrap();
	let old_manifest = self
	.old_date_version
	.as_ref()
	.and_then(|(d, _)| date_from_manifest_date(d))
	.unwrap_or(first_manifest);
	let last_manifest = if self.allow_downgrade {
	first_manifest
	} else {
	old_manifest
	};

So basically it's using the Manifest::date field as the source of truth, and this only applies to nightly so far.

So my proposition is to generalize this comparison to work with other channels including stable. Also, we can expose the allow_downgrade flag to rustup update. The actual comparison logic remains to be determined, but I think it can involve the manifest date and/or the toolchain version (saved in self.old_date_version).

[rami3l]

@neolib Would you mind comparing the manifest dates of your first and second mirror servers (or, alternatively, you can provide the exact mirrors you have used, and I can check it for you)? I've spotted a bug in our codebase that might cause unexpected downgrades even if --allow-downgrade is disabled.

IMHO, once I fix that, checking the manifest dates should be sufficient in your case, in that we should normally only allow rustup update to use the manifest of the same or a newer date.