Subject: Re: [boost] Enabling spectre mitigation in boost libraries
From: Riff J (r12f.code_at_[hidden])
Date: 2019-04-06 19:52:49
On Sat, Apr 6, 2019 at 11:48 AM Robert Ramey via Boost
> OK so the complete answer to the poster's question would be:
> a) build you're own instance of boost libraries - at least the ones that
> you use.
> b) with options that you need and the name/root you want do use.
> c) and test those builds with the tests provide for each library
> d) and report any problems.
> Is the information easily available in the Boost Build documentation to
> do this? I think it should be. In fact I think every time a question
> like this comes it, the boost library and tool maintainers should add a
> section to the the boost build documentation: Example ... or Case Study
> ... . Since the same questions tend to be posted again and again,
> eventually the need to make such additions to the manual will will taper
> off. At that point all these kinds of questions can be answered with a
> simple "see example ... in the documentation (you lazy moron). So,
> though my suggestion seems like it would be creating more work, it's
> actually an investment of effort designed to diminish total amount of
> work required to support the tool.
> Robert Ramey
Hi Robert, I get what you're saying, and we don't mind to build our
own version. But this issue is not a regular issue, like some minor
macros/flag we want to enable to fix some build errors. It is a
serious one. And for mitigating it, MSVC team even released a special
version of CRT (https://devblogs.microsoft.com/cppblog/spectre-mitigations-in-msvc/).
We do have other issues while fitting boost into our build system, but
we never reached out for those things. We only reached out for this
one, as we believe this is the better way to fix it and can help the
entire community. Please help reconsider it again.
Also please pardon the delay of my message. Maybe I misused the mail
list, somehow all of my messages need to be approved, so it might take
On Sat, Apr 6, 2019 at 11:55 AM Robert Ramey via Boost
> Forgot to mention: I don't think any kind of important code should be
> depending on binaries. For this reason, I don't think that Boost should
> be distributing binaries at all. To me, it's bad practice.
> I realize that in some cases it's unavoidable, (libc, etc. zlib,
> et.all). But still, I should be less preferred option for code which
> requires any consideration of modern security problems.
> Robert Ramey
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk