I understand that this is a serious issue. But it's not a mass developer problem. The majority of the software written is not impacted by this problem as it does not allow the manipulation through external end-user means and/or have security sensitive information to deal with. Hence such precompile Boost libraries would see a significant lower use than the current binaries. And the current binaries see a significant lower use than the source code (i.e. developer compiled). And hence I don't see the value of Boost itself providing such precompiled libraries. If Microsoft feels this is truly an important concern that needs to be addressed Microsoft could build Boost in that configuration and provide them for the rest of the world to use.
+1 Security conscious end users are going to recompile everything according to their own verification and audit processes in any case. They won't use precompiled binaries from external parties unless utterly unavoidable. So to me, apart from fixing the build errors mentioned when compiling with spectre mitigations enabled (pull requests welcome), this is not an issue the release managers need solve. I might also add that simply flipping on /Qspectre is horribly incomplete, and provides a false sense of security. An actually robust spectre mitigation involves very significant rearchitecture of an application, particularly to eliminate as many shared libraries as possible, and to hand-walk every single code path controllable by outside parties looking for timing-related information leak vectors. This is not something which Boost can, or should, do. Niall