getrandom 0.3.4 has MSRV 1.63; *-windows-* targets support Windows 7 until 1.76

[briansmith]

IIUC, getrandom 3.4 will use the ProcessPrng backend for *-pc-windows-msvc (and others). If building with the Rust 1.63 toolchain, then a Windows-8-compatible executable will be created. But, the logic in windows.rs using ProcessPrng assumes that it is running on Windows 10 or later. This seems wrong; the logic should be modified to correctly support Windows 8.

See PR #811 for other reasons that the logic should be changed.

[josephlr]

For getrandom 0.3.4 (for example), on Rust 1.77 and earlier, we use the windows_legacy backend, which unconditionally uses RtlGenRandom.

So we should be good as RtlGenRandom has been around since at least the XP days.

[briansmith]

Consider the case where one is using a build system that intentionally avoids building/running build.rs and is using Rust 1.75. In that case, the non-legacy backend would be chosen, IIRC.

[josephlr]

Correct, if a user chooses to not use our build.rs they would need to pass getrandom_backend="windows_legacy" on Rust 1.77 or earlier, but that seems compatible with our MSRV garuntees.

If a user is importing a crate into a system that doesn't want to use build.rs, it's on the user to correctly emulate the behavior in that script (if it matters to them). For example, this is what we have to do when importing crates into Google's monorepo in some cases.

[briansmith]

On master, the Windows logic isn't in build.rs any longer, so it is somewhat of a moot point, but: If we are assuming that either the build.rs is run or the user emulated the logic in it, then a better way to handle it would have been to always set a getrandom_default_windows_backend=windows_legacy or getrandom_default_windows_backend=windows and have the build fail when getrandom_default_windows_backend is not set. This way it isn't possible to get a buggy build when one accidentally ignores or misunderstands the build.rs, or when the build logic for choosing getrandom_backend is otherwise buggy. IME most developers are not so careful to get this right.

Note that this is a particularly big hazard for people upgrading from 0.2.x to 0.3.x, because 0.2 didn't have a build.rs at all and it is tempting to just ignore the build.rs since it seems to "work" without it.

[newpavlov]

Is it common to disable build.rs in the first place? I would say that any potential breakage caused by such unconventional setup is user's responsibility.

This problem no longer applies to v0.4 because of the sufficiently high MSRV and I don't think we should bother with backport changes to address this.

[josephlr]

In my experience for Windows on getrandom 0.3, folks either want:

• the behavior in the build.rs (selecting backends based on compiler version), in which case they run the build.rs.
• to only use ProcessPrng (see this chromium issue), in which case they can just not run the build.rs script and the windows backend will be chosen by default.

This seems like a reasonable setup, and it literally only has problems if you are both:

• Ignoring our build.rs (unsupported)
• Using a Windows version older than Windows 8 or Windows Server 2008 R2

[newpavlov]

if you are both

And use Rust compiler older than 1.76.

[newpavlov]

Closing per the comments above.