[Bro-Dev] 0MQ security considerations

[Robin Sommer]

On Sun, Jul 17, 2011 at 08:32 -0700, you wrote:

> threads, tasks/futures, smart pointers, SFINAE helpers like
> boost::enable_if, RNGs, etc. Overall, I find myself needing less time to
> write more code that actually does something.

I believe all of that!

However, my main concern is that I don't want to introduce such
functionality through the backdoor by starting to use it here and
there. That leads to code that's really hard to maintain because one
suddenly has a mix of different styles, idioms, level of abstractions,
etc.

For Bro, we had this in the past already with STL containers: they
slowly started to being used more and more, and now we have quite a
mix all over the code. I like the STL containers and I certainly
prefer to use them over the macro-based alternatives (and I do use
them where I can these days), but I still don't think that having both
versions in the same code base is a good thing.

Containers aren't really that critical in this context as it's rather
clear to see what's going on (though there are cases where we now need
to convert from container type A to B). But I'm not sure that also
applies to all the shiny new features in C++11 ... 

So, generally, I'd be fine switching to using more modern stuff but I
think that needs to be a conscious decision and we need to adapt the
existing code base accordingly. We also need to make sure we have the
platform support everywhere we need it; don't think we are there yet
(or are we?).

Coming back to the original question, in my view triggering all this
is not really justified just for doing threaded loggging. Longer term,
it may be fine.

> If we really want to use Boost (say to have a platform-independent
> networking library), we could whitelist the Boost components that we
> allow in Bro.

That's a slippery slope. With that, everytime somebody wants to use
something else (which is always tempting of course :), we'd need to
argue about it and potentially find arguments for *not* using it;
which will be hard I'm sure. Or somebody might just start using it and
"will change that later" ... 


(Btw, DataSeries uses Boost. So folks using that will need that
dependency already. And it's quite a bit one as I noticed when
installing the Boost FreeBSD port the other day ...)

Robin

-- 
Robin Sommer * Phone +1 (510) 722-6541 * robin at icir.org
ICSI/LBNL    * Fax   +1 (510) 666-2956 *   www.icir.org