Boost logo

Boost :

Subject: Re: [boost] Library for configuration file parsing
From: Joel de Guzman (joel_at_[hidden])
Date: 2010-11-29 19:10:51

On 11/30/2010 6:56 AM, Marsh Ray wrote:

>> Why do you have to grok the internals of a library in order to use it
>> successfully?
> For most programs - you don't. Most code is written to the garbage-in-garbage-out
> standard. For valid inputs it is tested to produce valid outputs.
> Well-written code goes the extra mile and tries to have well-defined handling even for
> invalid input.
> But there's a third level for code in internet-facing apps that handles untrusted data. In
> this case it has to be resilient against even actively malicious inputs crafted by a
> skilled attacker. Proving the negative (there are no possible inputs which can produce
> undesired behavior) is usually harder than proving the positive (these valid inputs
> produce desired behavior). Experience shows that this kind of code doesn't happen by
> accident, even from the most solid traditional software process.
> The state of secure coding art seems to be today much like where "software quality"
> processes were way back when we were just discovering things like unit testing. So we
> still fall back to subjective human judgement in most cases: has the code been reviewed
> for security? Did the reviewers find it comprehensible? In good taste? How many security
> holes did they find? Are the developers willing to stand behind? Even beyond its original
> design requirements?


>> I've almost had enough of this FUD mongering.
> I'm sorry that you feel that way. It was not my intention to cast FUD.
> C++ and Boost are well suited for secure coding because of the support for type safety,
> automatic cleanup, and overall deterministic execution. But probably nothing will replace
> the need to understand what's going on under the hood as well as the attacker.

If that is your reasoning then you can't use Boost (nor cpp-netlib
for that matter). "The number of "eyes" that can grok" Boost internals "and
accurately review it are vanishingly small." Yet, anyone claiming to be
a C++ security expert positioned to review code for "software quality"
should be able to review any and all sort of C++ code, even the template
heavy code like MPL. Spirit is not special. It uses the same template
metaprogramming techniques that is prevalent in most of Boost libraries.
There is no black magic there.

[I'll try to reply to your Spirit related comments in another post.
As I see it, your comments there (relating to not being able to
make it your code work and that JSON is easy to code in C) is totally


Joel de Guzman

Boost list run by bdawes at, gregod at, cpdaniel at, john at