gfx-rs
Yank versions of wgpu without #5812?
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 https://github.com/rust-lang/rust/commit/38104f3a8838f8662ad3cccc4d7262a96bf9724 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.
This goes back to the introduction of 81569dd6c3ad58dea3d42c36c4c4b71087572ca5 sooo wgpu 0.15.0 it seems?
That is a... lot of versions to yank, so I think it would be most productive to, e.g.
- yank wgpu 0.20.0 and 0.20.1, since the patch is in 0.20.2 and that would force the upgrade (thus, having an actual practical effect)
- decide on a disposition for #5833
- consider yanking previous 0.19 versions if the answer is "merge"
- decide on a disposition for #5834
- consider yanking previous 0.18 versions if the answer is "merge"
- only then consider 0.17, 0.16, and 0.15
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.
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.
The 0.19.* series has been updated and yanked, with CHANGELOG entries backported to trunk:
Will tackle 0.18.* tomorrow.
Do you know that yanking those crates broke all versions of Deno except for the current one (1.45), released last week?
❯ cargo update
...
error: failed to select a version for the requirement `wgpu-core = "^0.20"`
candidate versions found which didn't match: 0.21.1, 0.19.4, 0.19.3, ...
location searched: crates.io index
required by package `deno_webgpu v0.125.0`
... which satisfies dependency `deno_webgpu = "^0.125.0"` of package `deno_runtime v0.166.0`
...
Update: The yanking affects all Deno releases of 1.43 and 1.44, reaching back to May 1.
Hotfix for people using Deno 1.44:
[workspace.dependencies]
# Deno v1.44.4
deno_core = "=0.290.0"
deno_runtime = "=0.166.0"
[patch.crates-io]
wgpu-core = { git = "https://github.com/gfx-rs/wgpu", tag = "v0.20.0" }
wgpu-types = { git = "https://github.com/gfx-rs/wgpu", tag = "v0.20.0" }
@mlafeldt: That breakage implies a build attempting to either create a lockfile from scratch, or update a lockfile's wgpu* dependencies. Projects with an existing Cargo.lock that aligns with existing Cargo manifests should continue to build as before.
Will summon @crowlKats here specifically on the topic of Deno support and/or help understanding where Deno integration will go from here.
Our stance is that there isnt much we can do here, and we recommend using a working version. And as @ErichDonGubler mentioned, if you have an existing Cargo.lock, it should work.
This is part of why Cargo changed their guidance to recommend that even a library should consider committing the lockfile.
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. ✌🏻
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! :zany_face: 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.
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.
tbh I'm also confused why cargo update -p wgpu --precise 0.20.1 isn't the recommended "workaround", exactly.
@gfx-rs/wgpu: Given the decision in https://github.com/gfx-rs/wgpu/pull/5834#issuecomment-2312911602 to not go forward with the 0.18 backport, should we still yank the 0.18.* series? Leaning towards yes.
@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.
Also noticed that we hadn't yanked 0.19.0-3 versions of wgpu-core, so I've done that.
EDIT: s/*/0-3
Was wgpu-core 0.19.5 not released? Getting the following while building Bevy at tag v0.13.2:
error: failed to select a version for the requirement `wgpu-core = "^0.19.0"`
candidate versions found which didn't match: 22.1.0, 22.0.0, 0.21.1, ...
location searched: crates.io index
required by package `wgpu v0.19.3`
Attempting to bisect a separate issue and this is pretty inconvenient.
@rparrett: Ah, I'd yanked wgpu-core 0.19.4, but I think it might not need to be yanked (because we can force new code to use wgpu-hal 0.19.5).
To answer your question directly: No, wgpu-core 0.19.5 is not a release we ever made. wgpu-hal 0.19.5 exists (and is the only version of wgpu-hal we consider safe for general consumption because of this issue), but wgpu-core did not have any changes at the time wgpu-hal 0.19.5 was released.
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.
Interest in backporting has died down and we're on v24 right now, so I'm going to call this closed.