Make a new release to address security issues found by cargo audit

[martin-t]

The latest version is 0.25 which appears to transitively depend on nix versions 0.20 and 0.18, both of which have vulnerabilities in them. It also appears that the Cargo.toml in latest master has already updated the dependencies which import these old versions. So to fix it, all winit needs to do is release a new version so downstream crates can update.

For reference, I found these issues when running cargo audit on rg3d (we use it as part of CI), here's the relevant issue: FyroxEngine/Fyrox#208

Also note that running cargo audit on winit's latest master will report two more issues. they are in the time and chrono crates which are however only dev-dependencies of winint so these should not affect downstream crates (if my understanding is correct and if cargo audit treats dev-dependencies properly).

[maroider]

Hi. Thanks for taking the time to file this issue and the accompanying PR (#2039).

Grepping through the sources in my cargo registry ($HOME/.cargo/registry/src) after checking out 0.25.0 and cargo check-ing for both Linux and macOS did not yield any instances of getgrouplist in any crate that winit depends upon, directly or indirectly.

With that in mind, I think it is safe to assume that winit isn't affected by the issue in question.

[martin-t]

That's strange. On my computer, running cargo check on the 0.25.0 tag downloads nix-0.18.0 and nix-0.20.2 which both call libc::getgrouplist.

Interestingly, i am not sure what i did but when deleting Cargo.lock and running cargo audit or cargo check, sometimes ended up with nix-0.20.0 and sometimes with nix-0.20.2. But either way, the vulnerable nix-0.18.0 was always there.

You can also try running cargo tree - nix-0.18.0 should be there. Relevant part of the dep tree:

winit v0.25.0
├── smithay-client-toolkit v0.12.3
│   ├── calloop v0.6.5
│   │   └── nix v0.18.0
│   ├── nix v0.18.0 (*)

Finally, don't forget that checking out a different commit doesn't update Cargo.lock and cargo audit doesn't currently do it on its own: rustsec/rustsec#322

Oh and actually, i found out that sometimes if you have an existing Cargo.lock, then check out a different version and run cargo check, it might resolve to slightly different versions than if you deleted the lock and therefore started from scratch. I think it's trying to reuse downloaded/compiled deps, not sure.

[maroider]

That's strange. On my computer, running cargo check on the 0.25.0 tag downloads nix-0.18.0 and nix-0.20.2 which both call libc::getgrouplist.

nix only seems to call libc::getgrouplist in nix::unistd::getgrouplist. With that in mind, we can ignore any matches on getgrouplist in nix and libc. If we get no matches elsewhere, then I think we can assume (in the absence of hackery like paste/concat_idents) that winit does not call the function, directly or indirectly. Indeed, getgrouplist appears to be absent when looking through the dynamically imported functions of a binary with winit in it.

Finally, don't forget that checking out a different commit doesn't update Cargo.lock

I am aware, yes, and I deleted Cargo.lock immediately after checking out different revisions.

[martin-t]

Ok, thanks for the analysis. I updated our issue saying that the advisory can be safely ignored. I guess this can be closed.