Re: [Boost-users] Dealing with resistance to Boost

Subject: Re: [Boost-users] Dealing with resistance to Boost
From: Sebastian Redl (sebastian.redl_at_[hidden])
Date: 2012-07-12 04:16:26

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