Update bundled musl to 1.2.5

[Gankra]

Update the bundled musl library from 1.2.3 to the 1.2.5 release from February 29, 2024.

• mcp: Upgrade *-linux-musl targets to musl 1.2.5 compiler-team#887
• blog: Create Updating-musl-1.2.5.md blog.rust-lang.org#1641
• Prior update: Update the version of musl used on *-linux-musl targets to 1.2.3 #107129
• musl releases page

---

This is a rebase of

• Update bundled musl to 1.2.5 #125692

Which removes the second speculative commit which ended up not panning out.

I've added my own second commit that updates all other places I could find that referenced musl 1.2.3 in the codebase.

try-job: dist-x86_64-musl
try-job: dist-i586-gnu-i586-i686-musl
try-job: dist-x86_64-linux

[rustbot]

r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[rustbot]

These commits modify compiler targets.
(See the Target Tier Policy.)

Some changes occurred in src/doc/rustc/src/platform-support

cc @Noratrieb

[Gankra]

The previous PR stalled out on concerns of ecosystem breakage, but see this comment for @est31 concluding we can move forward without further mitigation: #125692 (comment)

[Gankra]

I would like to nominate this for FCP or whatever the current process is to land these kinds of major toolchain changes.

Landing this update is expected to resolve ongoing issues in the ecosystem with rootless docker images.

I've also drafted a rust-lang blogpost announcing this change (based on the previous musl update's post).

[jieyouxu]

The process for bumping the target baseline of Tier 2 targets is currently a Major Change Proposal + FCP (see Changing target baseline (e.g. minimum Darwin or Windows version bump) part). If you draft an MCP, I'll help with the notifying relevant target maintainers part.

Changing target baseline (e.g. minimum Darwin or Windows version bump)

• Propose using: MCP
• Approve using: FCP
• Write an MCP describing why the target should have a change of baseline and once discussion has concluded, an FCP can be started to approve the change of baseline.

[jieyouxu]

r? @wesleywiser (since you've reviewed the previous attempt)

[Gankra]

I have filed an MCP:

• Upgrade *-linux-musl targets to musl 1.2.5 compiler-team#887

[workingjubilee]

Building host compiler plus musl stds for crater run.

@bors try

[bors]

⌛ Trying commit 1926e11 with merge 1271e16...

[bors]

💥 Test timed out

[workingjubilee]

@bors2 delegate=try

[rust-bors]

@Gankra can now perform try builds on this pull request

[craterbot]

🚧 Experiment musl_upgrade_1_2_5_with_getrandom_patch_1 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[craterbot]

🎉 Experiment musl_upgrade_1_2_5_with_getrandom_patch_1 is completed!
📊 0 regressed and 0 fixed (690133 total)
📊 428 spurious results on the retry-regessed-list.txt, consider a retry¹ if this is a significant amount.
📰 Open the summary report.

⚠️ If you notice any spurious failure please add them to the denylist!
ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

Footnotes

1. re-run the experiment with crates=https://crater-reports.s3.amazonaws.com/musl_upgrade_1_2_5_with_getrandom_patch_1/retry-regressed-list.txt ↩

[Gankra]

That's a legit result right? Just, totally clean?

[Skgland]

That's a legit result right? Just, totally clean?

The Full Report is full of broken crates.
Not sure what went wrong as all try run logs appear to be missing.

[Skgland]

+patch=getrandom=ssh://[email protected]/rust-random/getrandom=backports/v0.2 should correspond to adding the following in Cargo.toml

[patch.crates-io]
getrandom = { git = "ssh://[email protected]/rust-random/getrandom", branch = "backports/v0.2" }

with that I get the following when applying it to a local project

$ cargo check
    Blocking waiting for file lock on package cache
    Updating git repository `ssh://[email protected]/rust-random/getrandom`
error: failed to load source for dependency `getrandom`

Caused by:
  Unable to update ssh://[email protected]/rust-random/getrandom?branch=backports%2Fv0.2

Caused by:
  failed to fetch into: /home/bennet/.cargo/git/db/getrandom-e56c77e0754fdde0

Caused by:
  failed to authenticate when downloading repository

  * attempted ssh-agent authentication, but no usernames succeeded: `git`

  if the git CLI succeeds then `net.git-fetch-with-cli` may help here
  https://doc.rust-lang.org/cargo/reference/config.html#netgit-fetch-with-cli

Caused by:
  no authentication methods succeeded

Also, does crates/rustwide even have an ssh key setup to checkout repos via ssh?

Using https:// instead appears to work locally

[patch.crates-io]
getrandom = { git = "https://github.com/rust-random/getrandom.git", branch = "backports/v0.2" }

i.e.

+patch=getrandom=https://github.com/rust-random/getrandom.git=backports/v0.2

I remember testing this, but apparently in a different environment where I had configured cargo/git/ssh to be able to use an ssh key, so I missed this failure mode.

[workingjubilee]

I don't think this is worth continuing to run crater on and trying to figure out, because we already had rough consensus that any crater usage was purely informational.

[Gankra]

I've rebased the PR and I think I've fixed:

Just FYI, this pull request effectively only changes the musl version in the musl-cross-make script (which is only used by aarch64 and x86_64), the crosstool-ng configs used by all the other targets still need updating.

In particular we're currently on crosstool-ng 1.27 which defaults to musl 1.2.5, so all that needed to be changed was to remove explicit opt-outs for that version. The only opt-out I could find was for powerpc64le-unknown-linux-musl.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[wesleywiser]

If we could get crater to cooperate, that would be great (and I think it seemed to work when I bumped musl last time):

@craterbot run mode=build-and-test name=musl_upgrade_1_2_5_with_getrandom_patch_2 start=try#8de4c7234dd9b97c9d76b58671343fdbbc9a433e+target=x86_64-unknown-linux-musl end=try#c066bf6804adc55193b71afdff6a56922f4a8689+target=x86_64-unknown-linux-musl+patch=getrandom=https://github.com/rust-random/getrandom=backports/v0.2
crates=https://gist.githubusercontent.com/workingjubilee/075aa4757096ce213b76d576f2f92742/raw/197ec4b1e9a09e208b6863172f6a1e9baceaa842/musl-1_2_5-retry-list-4.txt

[craterbot]

👌 Experiment musl_upgrade_1_2_5_with_getrandom_patch_2 created and queued.
🔍 You can check out the queue and this experiment's details.

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more

[wesleywiser]

Overall looks good to me, just a few small comments.

View changes since this review

[wesleywiser]

I think we should bump to 7b4c7b315226835bab03da73a45945acb1b3bedf or higher to pick up the patches for CVE-2025-26519

[Gankra]

bumped to the latest commit

[Gelbpunkt]

In particular we're currently on crosstool-ng 1.27 which defaults to musl 1.2.5, so all that needed to be changed was to remove explicit opt-outs for that version

I'd recommend still pinning the musl version explicitly so that another crosstool-ng update doesn't unintentionally bump musl to future releases. Effectively, all but 3 targets are now already using 1.2.5 even though that wasn't intended. Pinning the version like is currently done for ppc64le would prevent this.

[Gankra]

I'd recommend still pinning the musl version explicitly so that another crosstool-ng update doesn't unintentionally bump musl to future releases. Effectively, all but 3 targets are now already using 1.2.5 even though that wasn't intended. Pinning the version like is currently done for ppc64le would prevent this.

done

[craterbot]

🚧 Experiment musl_upgrade_1_2_5_with_getrandom_patch_2 is now running

ℹ️ Crater is a tool to run experiments across parts of the Rust ecosystem. Learn more