Ring: Release 0.11.1 to dismiss Spectre warning on MSVC

[neoeinstein]

Could you create a 0.11.1 patch release to ignore the spectre warning on Windows MSVC? The line that is in the current master is:

    "/wd5045", // C5045: Compiler will insert Spectre mitigation for memory load if /Qspectre switch specified

I am currently using yup-oauth2, which, through a dependency chain, is locked to the 0.11 line of ring. My windows developers are now unable to build our project due to the spectre warning being emitted by the latest MSVC build tools, so a small point release would be appreciated.

[pietro]

@neoeinstein as a workaround you can set the environment variable CL="/wd5045" to disable the warning.

[briansmith]

The latest release of ring is free and I help people use the latest version of ring; for example, I fixed this problem in the build system in the latest release of ring already. I hope people can work together to help each other upgrade to the latest release. Failing that, if people need help with older versions of ring, they can email me at [email protected] to work something out.

[neoeinstein]

Thank you for the suggestion, @pietro. I will give that a go and see if that unblocks us.

@briansmith Yes, I am aware that _ring_ is free, and I saw that you had already fixed the issue in the current release of _ring_. My code block above was a copy of exactly that one line. There are multiple levels where I am trying to take small steps to unblock various components in the Rust ecosystem, many of which do not use the latest _hyper_ in order to avoid async until the dust settles there. Sadly, many of these components are buried under several dependencies which will express the same "only latest" support model. I was looking for the change in the ecosystem (or a workaround) that would have the fewest knock-on effects. I could not submit this as a PR, as I was asking for a branch off the 0.11 tag with one commit and a publish. My apologies for bothering you. If my team runs into similar problems in the future, we now are on notice that we will have to find our own way until the Rust ecosystem settles down.

[briansmith]

@neoeinstein No worries. I am a big proponent of the "only latest" model. In the "only latest" model is that nobody is on their own; the idea is that everybody works together to keep things up to date, so we don't waste time maintaining older versions and we can spend more time improving the master branch of every project. I've found projects to be very welcoming of PRs that upgrade them to the latest release of ring; I've submitted many dozens of PRs of that sort.

[ctz]

There are multiple levels where I am trying to take small steps to unblock various components in the Rust ecosystem, many of which do not use the latest hyper in order to avoid async until the dust settles there

I'm not sure what your dependency tree looks like, but I maintain a non-async hyper-0.10 branch of hyper-rustls for this kind of reason. If it helps fix your problem I'm happy to push another 0.6 release of that?