Boost logo

Boost Users :

Subject: Re: [Boost-users] Dealing with resistance to Boost
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2012-07-12 05:23:10


 

 

From: boost-users-bounces_at_[hidden] [mailto:boost-users-bounces_at_[hidden]] On Behalf Of
hano botha
Sent: Wednesday, July 11, 2012 5:02 PM
To: boost-users_at_[hidden]
Subject: [Boost-users] Dealing with resistance to Boost

 

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.

 

> 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?

 

Any good references would be great.

 

See which other companies are using Boost

 

http://www.boost.org/users/uses.html

 

(and this doesn't mean that they are good or bad companies, just that lots of users are not finding
security risks).

 

Boost libraries have their share of bugs and 'features' but their very wide use tends to mean that
they are found and fixed, and the release cycle is such that they are fixed much more quickly than
some commercial suppliers 2 year cycle (and you can often get a 'hot fix' even more quickly from
Boost trunk via SVN).

 

Source code of everything is fully visible, even if you use compiled libraries (which you have to do
for some libraries). What You See Is What You Get ;-)

 

To my knowledge, there has never been anything that could possibly be described as 'malware'.

 

HTH

 

Paul

 

 



Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net