-----Original Message-----
From: Boost
Hi everyone,
I am a developer from Microsoft and currently using boost in our project. We recently get noticed by our security team, that the boost library we use, are not compiled with spectre mitigation (/Qspectre) enabled. Since boost is super powerful, it might not be a good idea to write our own or maintain our own version, so we are reaching out for help. Could anyone please help see if we could enable /Qspectre option in the official build of boost?
We tend to use default compiler flags for official builds, but it's relatively easy for you to build Boost with whatever other flags you may want: cd boost-root-dir bootstrap b2 --build-type=complete cxxflags=-Qspectre Will build the libraries with the latest installed msvc version and the /Qspectre flag enabled. And of course for header only libraries you don't need to do anything at all anyway. One thing we could look at for future releases would be to provide differently-named binaries for /Qspectre. Anyone else have thoughts on that? That works for me for a small subset of 'core' libraries. Before we get too excited about this, perhaps we should see if using the /Qspectre option does anything by checking how many warnings we get from https://devblogs.microsoft.com/cppblog/spectre-diagnostic-in-visual-studio-2... by enabling C5045 ? I've done this building a few core libraries for msvc-14.2 Adding cxxflags=/w35045 And I get a blizzard of warnings, almost exclusively from MS code mainly about buffer sizes in handling of strings. However, date-time and filesystem do produce some warnings ☹ Calculation of buffer and string sizes mainly. Unit test framework also has some warnings - but one would probably not care about some testing code that should never 'hits the streets'. (C strings are the worst idea ever). I wonder if some of these could be 'fixed' by making the lengths static and/or const or constexpr? But anyone using this is going to have to ensure that absolutely everything is compiled with the /Qspectre option. MS say that the performance cost is negligible I think we should handle this by changing the documentation to provides links to this and, for now at least, leave users to handle building their own libraries and using with their own code. If there proves to be popular demand, we could consider a new set of libraries. My two pennyworth. Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK
And here is the vcblog about the spectre mitigation, if anyone is interested: https://blogs.msdn.microsoft.com/vcblog/2018/01/15/spectre-mitigations -in-msvc/