[Bro-Dev] 0MQ security considerations

[Matthias Vallentin]

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

I fully agree.

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

Assuming there is not performance/functionality issue, is it too much of
an effort to replace the ancient containers?

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

Eventually, it could be worth going through the new list of language and
library features, compare them to the Status Quo, and decide if a change
makes sense. For example, there could be smart pointer branch that
replaces (Un)Ref() calls with std::shared_ptr.

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

At least all platforms that support gcc 4.7+ should have no trouble, but
I'm sure it will still take a while until we have solid C++11 compilers
that are stable on all platforms.

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

For just threaded logging, I agree. But this seems to be a rather
general questions. I believe that just enhancing one component of Bro
with thread support can lead to a problematic architecture in the long
run, when other components also jump on the concurrency train. If this
is not a coordinated effort, the components may crossfire and impede
themselves. This could be as simple as thread thrashing but als manifest
more subtle with poor caching and memory performance. Maybe it's not
warranted at this point, but I think we should at some point think about
a task-based approach to concurrency, rather than thinking about
concurrency in terms of threads. (This is completely independent of the
multi-core Bro effort but rather about general software engineering
practices in many-core land.)

> 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" ... 

Fair enough. But at the end of the day we have to make a decision about
what platform-independent network and I/O framework to use. The Boost
networking library is of high quality and used widely. If we find a
slimmer alternative, that would be great.

    Matthias