Re: [boost] Enabling spectre mitigation in boost libraries

Subject: Re: [boost] Enabling spectre mitigation in boost libraries
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2019-04-07 08:21:04

> 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