Bump mio to v0.8.11

[aaronmondal]

Fixes https://osv.dev/vulnerability/RUSTSEC-2024-0019

---

This change is 

[aaronmondal]

+@allada +@MarcusSorealheis +@adam-singer +@zbirenbaum

Reviewable status: 0 of 4 LGTMs obtained, and pending CI: Analyze (javascript-typescript), Analyze (python), Bazel Dev / ubuntu-22.04, Cargo Dev / macos-13, Cargo Dev / ubuntu-22.04, Local / ubuntu-22.04, Remote / large-ubuntu-22.04, Vercel, asan / ubuntu-22.04, docker-compose-compiles-nativelink (20.04), docker-compose-compiles-nativelink (22.04), integration-tests (20.04), integration-tests (22.04), macos-13, pre-commit-checks, publish-image, ubuntu-20.04 / stable, ubuntu-22.04, ubuntu-22.04 / stable, vale, windows-2022 / stable, zig-cc ubuntu-20.04, zig-cc ubuntu-22.04 (waiting on @adam-singer, @allada, @MarcusSorealheis, and @zbirenbaum)

[adam-singer]

Reviewed 1 of 1 files at r1, all commit messages.
Reviewable status: 1 of 4 LGTMs obtained (waiting on @allada, @MarcusSorealheis, and @zbirenbaum)

[allada]

Reviewable status: 1 of 4 LGTMs obtained (waiting on @MarcusSorealheis and @zbirenbaum)

---

Cargo.lock line 1631 at r1 (raw file):

[[package]]
name = "mio"
version = "0.8.10"

Modifying it this way probably means we cannot easily regen this file, right?

[aaronmondal]

Reviewable status: 1 of 4 LGTMs obtained (waiting on @allada, @MarcusSorealheis, and @zbirenbaum)

---

Cargo.lock line 1631 at r1 (raw file):

Previously, allada (Nathan (Blaise) Bruer) wrote…

Modifying it this way probably means we cannot easily regen this file, right?

The Cargo lockfile isn't reproducible anyways. There is only cargo update to update all dependencies, cargo update somecrate to update a specific crate and cargo update somecrate --precise 1.2.3 for a precise version update.

In this case mio is not an explicit dependency so it doesn't have a counterpart in any Cargo.toml. But AFAIK Cargo's resolution mechanism wouldn't let us perform this update if it conflicted with some dependency (I ran cargo update mio without the precise flag).

[zbirenbaum]

Reviewable status: 1 of 4 LGTMs obtained (waiting on @allada and @MarcusSorealheis)

---

Cargo.lock line 1631 at r1 (raw file):

Previously, aaronmondal (Aaron Siddhartha Mondal) wrote…

The Cargo lockfile isn't reproducible anyways. There is only cargo update to update all dependencies, cargo update somecrate to update a specific crate and cargo update somecrate --precise 1.2.3 for a precise version update.

In this case mio is not an explicit dependency so it doesn't have a counterpart in any Cargo.toml. But AFAIK Cargo's resolution mechanism wouldn't let us perform this update if it conflicted with some dependency (I ran cargo update mio without the precise flag).

Another option which would be reproducible would be shipping a forked version of tokio which has the dependency updated, and then making an issue so they are aware to update it. Then we could migrate back once they do.

[allada]

Reviewable status: 2 of 4 LGTMs obtained (waiting on @MarcusSorealheis and @zbirenbaum)

[zbirenbaum]

Reviewed all commit messages.
Reviewable status: 3 of 4 LGTMs obtained (waiting on @MarcusSorealheis)

[aaronmondal]

Reviewable status: 3 of 4 LGTMs obtained (waiting on @MarcusSorealheis)

---

Cargo.lock line 1631 at r1 (raw file):

Previously, zbirenbaum (Zach Birenbaum) wrote…

Another option which would be reproducible would be shipping a forked version of tokio which has the dependency updated, and then making an issue so they are aware to update it. Then we could migrate back once they do.

We'd have to vendor everything then though. And then it wouldn't be possible to reproduce the vendored closure, so we'd have the same issue as before.

I think the approach we currently use is fine since IMO the important thing is that the nativelink executable itself is reproducible, and that's the case here. We could make the lockfile "more" reproducible by specifying somedep = "=1.2.3" for all dependencies in our Cargo.toml files, but it's unclear to me whether that would actually make a difference for implicit dependencies.

We still have nativelink reproducibility for commit-wise roll-forwards and rollbacks since the lockfile is checked in.

[aaronmondal]

-@MarcusSorealheis

Reviewable status: complete! 3 of 3 LGTMs obtained