Yank versions of wgpu without #5812?

[workingjubilee]

Before d309bba, Direct3D was just merrily reading random uninit data into its execution. We know this for a fact because the very moment wgpu called a version of compile_fxc compiled by a rustc with rust-lang/rust@38104f3 on Windows, the programs got hoist on the petard of STATUS_ACCESS_VIOLATION. Much better, because the bug was made visible and has been quickly fixed! It is worth considering yanking affected versions of wgpu, especially those that have the fix backported to their major version, so that Windows stops munching on garbage data, and to accelerate retiring the affected versions from the ecosystem (even if it does not actually completely remove them due to how yanking works).

...Or not! I'm a programmer, not a cop.

[ErichDonGubler]

Bringing back in the consensus from the 2024-06-26 maintainers meeting: we intend to yank all affected release versions. We will provide patch releases for 0.19.* and 0.18.*, since the community has already shown interest, and backport PRs are open. If others want to take the time to backport for older (yanked) releases, we will consider on a case-by-case basis.

_{EDIT: Shared the above in Matrix for users and maintainers.}

[ErichDonGubler]

We have yanked the 0.20 and 0.21 series of wgpu-hal and wgpu-core, minus the latest 0.21.* release. We have also yanked the 0.20.0 release of wgpu in favor of the 0.20.1 release, which can optionally upgrade to the 0.21.1 release of wgpu-hal and wgpu-core.

I will be taking further time to merge v0.19 and v0.18 branch updates and post respective updates next week, after which previous releases in those minor version tracks with be yanked.

[ErichDonGubler]

The 0.19.* series has been updated and yanked, with CHANGELOG entries backported to trunk:

Will tackle 0.18.* tomorrow.

[workingjubilee]

This is part of why Cargo changed their guidance to recommend that even a library should consider committing the lockfile.

[mlafeldt]

I think we can all agree on how Cargo works.

My main question is whether a library crate should yank versions to promote a bug-fix release. Why isn't relying on semantic versioning enough?

Back to Deno:

Most people embedding Deno probably don't even use the WebGPU API (it's still unstable and disabled by default). Yet, they now have to deal with this issue, even if it only means that cargo update without -p won't work anymore (a big annoyance in a monorepo).

Please also consider that updating the Deno runtime can be difficult, as it has many dependencies and often backward-incompatible changes. This is especially true for ops and snapshotting, which can require significant refactorings (I'm still working on updating a FaaS backend to Deno 1.45).

Anyway, there's a workaround, which is all we need right now. ✌🏻

[workingjubilee]

Yes, in many cases, it is common to avoid yanking and to simply file a RUSTSEC advisory.

I do not think this is a point in favor of filing a RUSTSEC advisory, however. Many RUSTSEC advisories are... about hypothetical use-cases, and are issued well in advance of any proof of consequences "in the wild". It can be good to stay on top of these things, before anything "bad" actually happens.

However, in this case, the unsoundness is essentially always reached on Windows devices that must use the FXC support, by run-of-the-mill callers of the wgpu library. So, for applications depending on wgpu, this is a large number of Windows installations, and wgpu ships in not-just-hypothetical-and-feature-flagged cases, but to programs that always use it and will always execute the unsound code. By "weird mysterious segfault" standards, it was very easy to debug, precisely because it was so consistently unsound in actual usage.

This is the point at which yanking makes sense, which is why I suggested it for consideration. "This version is hella unsound" is indeed the most common reason I have seen a crate yanked. And this is, indeed, "hella unsound".

Where exactly to draw the line is subjective, which is why I tried to be slightly silly about it! 🤪 wgpu can have little a undefined behavior, as a treat!

...but I would ask you to consider that we would not be having this discussion if you maintained something that used wgpu on Windows. Or maybe we would, because perhaps we might have first started talking to each other when I replied to your rust-lang/rust issue about how your test suite was broken by the latest compiler version. Which would also require you to do something to mitigate the de facto breakage.

[cwfitzgerald]

So for some context, we yanked those versions (as opposed to letting versioning handle it like most other bugs) because if you run on dx12 at all, you're basically guarenteed to segfault on rust 1.78.

[workingjubilee]

tbh I'm also confused why cargo update -p wgpu --precise 0.20.1 isn't the recommended "workaround", exactly.

[ErichDonGubler]

@gfx-rs/wgpu: Given the decision in #5834 (comment) to not go forward with the 0.18 backport, should we still yank the 0.18.* series? Leaning towards yes.

[ErichDonGubler]

@jimblandy and I discussed with @cwfitzgerald in maintainer chat, and we are on board with yanking more versions without necessarily having a backport. We're uncertain how far back this issue goes in our release history, and we need clarity on that to determine when we're done yanking. For now, though, we can start with the 0.18 branch, which we do know has this issue.

[ErichDonGubler]

I have yanked 0.18.* versions of wgpu{,-{hal,core}}.

[ErichDonGubler]

Also noticed that we hadn't yanked 0.19.0-3 versions of wgpu-core, so I've done that.

EDIT: s/*/0-3

[ErichDonGubler]

Remaining scope: Determine how far back before the 0.18.* series (viz., 0.17.* and older) this issue extends. Yank everything that has this issue, and be ready to deal with supply chain fallout therefrom in this issue.