Backport changes necessary for mio 0.8 #413
Conversation
|
I'm hesitant to introduce a breaking change. And I'm currently considering making 5.0 release in the next few months and I'd go for it. |
|
Btw did you mean 4.0 not 0.4? |
|
Oh yep, I mean 4.0, sorry. I don't think this is a breaking change as I'm not changing any API of this package as far as I can see? |
|
But if you are planning to release 5.0 sometime soon, that would be the best! |
Oh sorry, I didn't check your changes carefully. MSRV CI failure is unrelated, but other failures are related? |
|
@0xpr03 This would bump our MSRV up to 1.46 (https://github.com/tokio-rs/mio/blob/master/CHANGELOG.md#080) It makes some sense to resolve the security advisory issue and 1.46 is old enough, so I think it's an acceptable breakage. Thoughts? |
This PR touches only Linux-specific code, so I don't think any failure on macOS or Windows is related. |
|
Well, I just realized ubuntu-latest's failure was only on MSRV check, I shouldn't work on serious things tonight... |
|
miow 0.2.2 had a patch for CVE-2020-35921 backported. I assume you came here from GHSA-jrcf-4jp8-m28v (Dependabot alerts), as that one doesn't seem to actually mention that 0.2.2 had this fixed. I submitted a correction to GitHub (github/advisory-database#365) to hopefully remove this alert. |
In itself yeah. |
|
Oh, wasn't aware that it has a fix backported. We probably don't need this then. |
|
Still thank your for taking the time. |
This PR backports necessary changes for mio 0.8 support to notify 4.0 branch.
This is because mio 0.6 depends on miow 0.2.2 which has an open security issue: https://rustsec.org/advisories/RUSTSEC-2020-0080.html and thus it's triggering warnings for packages using notify 4.x.
Since 5.0 is still in pre-release, and seemingly has been in the status for a long time, it might be better backporting mio 0.8 to 4.x branch and release a new version.