Consider migration from winapi-rs -> windows

[ctz]

It seems https://github.com/retep998/winapi-rs is now unmaintained due to https://github.com/microsoft/windows-rs (though the latter has some bananas build system)

(If we do this migration, we can replace ALLOWED_EKUS with [ szOID_PKIX_KP_SERVER_AUTH ]. We mustn't do that with winapi-rs, as this (and every other sz* constant string is dangerously wrong!)

[djc]

It might be useful to use windows-bindgen to generate bindings only for the symbols we need.

(Example setup from chrono: chronotope/chrono#1202.)

[complexspaces]

I also have a bit of experience with this, and I've taken different approaches in different crates. In sys-locale for example, I was only using ~3 items from the Windows headers and went with the bindgen-based approach. chrono looks to be in a similar situation. Otherwise I've used windows-sys and tried keeping its version synced with what tokio uses to be less burdensome on the ecosystem (see also #63 where this concern came up).

tokio is on windows-sys 0.52 right now, which is reasonable IMO. That only depends on windows-targets 0.52 which is helps provide "proper" linkage that is guaranteed to work in more places. The downside is that it slightly increases the lockfile size with the import lib wrapper crates.

In this crate, I imagine that we would only need to codegen wincrypt and some foundational types/errors. I think it may just get annoying if local changes are needed and constants/functions you want can't be autoimported by RA. It looks like chrono is using windows_targets anyway so I don't see a huge difference between a small subset of windows-sys vs custom generation TBH.

[complexspaces]

and every other sz* constant string is dangerously wrong!

FWIW I don't think they are wrong, I just think they require some extra care to use by default. Writing the constants as Rust strings is a lot more succinct, makes printing error messages and types easier, etc.

[djc]

It looks like chrono is using windows_targets anyway so I don't see a huge difference between a small subset of windows-sys vs custom generation TBH.

The problem that's been discussed is that windows-sys is a sizable download, so if you depend on a smallish part of it there's a bunch of effort wasted downloading and unpacking all that code.

[complexspaces]

17MB does seem to be a bit much, even though I think almost everyone is downloading this already.

I guess anyone doing local development of on rustls-platform-verifier can just manually substitute the dependency out temporarily, even if that would get old after a while.

[djc]

It's not a big deal -- I'd be okay with taking a dependency on windows-sys since this needs quite a bit more surface area than chrono (and is also itself a higher-level sort of library).

[cpu]

It seems https://github.com/retep998/winapi-rs is now unmaintained

I think the situation might be a bit more nuanced: rustsec/advisory-db#2031

[djc]

It seems https://github.com/retep998/winapi-rs is now unmaintained

I think the situation might be a bit more nuanced: rustsec/advisory-db#2031

While that might be true, the ecosystem is moving to windows-sys anyway so I still think joining that movement makes sense for this crate.

[cpu]

👍 I just wanted to make sure we represent the state of winapi-rs accurately. I agree switching to window-sys is the right call.