On 11.07.2012 18:02, hano botha wrote:

I am trying to get my organisation to use Boost.

I have managed to get it included in source control and we have permission to use it in our unit testing.

The main objection to using it in our production code is that it could be a potential security risk.

I suggested that we restrict the usage of boost to the template\ headers only libraries. I don't see how the templates in boost can cause more of a security risk than what we have currently with the STL.

What kind of security risk do you mean? Do you mean a risk to your company arising from potentially malicious code hiding in Boost? Do you mean that bugs in Boost would tear security holes into your application? If so, does your application routinely deal with untrustworthy data sources (anything on the internet), where the processing of data has to be absolutely robust? Or do you have to merely deal with, say, maliciously modified documents? Or is it the data channel itself that you fear might get attacked (say, if you use Boost.Asio to connect to the web). Either way, since Boost doesn't come with any binary code (just sources you compile yourself), there is not difference between the header-only libraries and the compiled libraries. They all pose the same risk.

My question is: How is vulnerabilities in the library dealt with? How is new vulnerabilities communicated to the user's community? I would also like to know historically, how many and how often were vulnerabilities discovered?

AFAIK, there never have been security vulnerabilities as such in the Boost libraries, because such a classification doesn't make sense here. A security vulnerability is a bug that makes it possible for an attacker of some kind to gain unauthorized access to a system or some data. General-purpose libraries like most of those in Boost may have bugs, but they only become security vulnerabilities in the context of an application that uses them. So the net question is, how often are there bugs in Boost libraries that could become a security issue? I think, from what I've seen on the bug tracker, that these are quite rare, but not non-existent. But they aren't given any special treatment: they are just bugs to be fixed. So there is no special process for dealing with security vulnerabilities or communicating them to the users. Check the bug tracker. Sebastian