[Snort-devel] Snort as a library

Daniel Roelker droelker at ...402...
Tue Jul 20 13:38:59 EDT 2004

On Tue, 2004-07-20 at 12:12, Michael Richardson wrote:
> Hash: SHA1
> >>>>> "Daniel" == Daniel Roelker <droelker at ...402...> writes:
>     Daniel> -Werror patch We'll look into it when we have time, but
>     Daniel> right now this does not affect functionality and is not a
>     Daniel> security issue so it's low priority.
>   I STRONGLY disagree. -Werror is critical. It finds portability bugs,
> and it catches lots of errors that programmers make. There were a number
> of places where functions were declared that did not match their
> prototypes. This is because there are prototypes missing for quite a lot
> of code, and other places where the .h file simply isn't included.

Again, this patch doesn't affect functionality and is not a security
issue, so it's still in the queue of submitted patches.  I'm not saying
that this type of checking isn't valid, but I am saying that there are
higher priority patches that we are looking at.

Just to give everyone an idea, we're still reviewing the massive
wireless patch and we are pretty excited about it.  In addition, we just
got sp_respond2 (with libdnet) from Jeff Nathan, which we've been
wanting to add in for a while.  We have all this in addition to writing
all the code that Marty, Marc, and me have signed up for in upcoming

All of these things take time to develop and audit properly, and certain
patches have priority over others.

>     Daniel> Global variable to structure You also submitted a patch that
>     Daniel> put global variables into a structure so you could run
>     Daniel> multiple "threads" that listen to different network
>     Daniel> interfaces.  This patch seemed to work for the embedded
>   No.
>   My goal is *NOT* threads. It happens that it might be useful for that
> as well. My goal is to be able to listen to multiple interfaces at the same
> time from the same executable. 
>   Yes, there embedded system involved --- but it actually has no threads
> at all. Not even processes. 

I didn't say your goal was threads.  That's why I used the same usage of
"threads" that you alluded to in your email when you posted the patch to
the list.

However, my main concern about adding this patch was that there was no
clear game plan for what you were doing.  You had eluded that this patch
could be used for adding multiple interface functionality, but this was
the first time that I had heard about this from you.

As you may know, the snort development team and this mailing list has
had many discussions about multiple interfaces in snort and we are
working on incorporating this feature in a future version of snort.

The structural changes that we would make for this feature may not be
the same changes that you would make.  We do try to clean up code when
we can, believe it or not, and adding this feature would give us a good
chance to revamp our initialization code and variables.  So most likely,
the changes we would make would be completely different, since you just
took the existing initialization code and put it into structure form.

>   This patch would eventually make it possible to listen to FD traffic
> using a pair of interfaces (something which has been asked for
> several times on the lists), but also for a single sensor to listen in
> multiple places and coorelate traffic.
>   No, it doesn't do all of that in the patch that is there. Attempting
> to do everything in one step is foolish, and as an open source
> maintainer, I always ask for structural changes to be seperated from
> functional changes so that the testing can be made simpler.

And as a developer, I always ask for requirements and design first
before we even start writing code, whether it be structural or
functional.  Multi-interface sniffing is a substantial feature and we
are not going to just take a first time contributor's patch that changes
core code and add it into our repository because they say it works fine
against their test suite.

Sourcefire has implemented QA and security audit requirements to every
piece of code that goes into snort.  Unfortunately, things have been
slowed down because of this, but we made these changes because we
believe we're producing a higher quality and more secure product and
code base by instituting these requirements.

>   I still await for some kind of explanation of what this testing is.
> I haven't looked at the latest release, I will do that soon. I hope it
> is there.

Brian Caswell is the best person to explain what this testing scheme is
covering, perhaps he can respond here or you can mail him directly?

Daniel Roelker
Software Developer
Sourcefire, Inc.

More information about the Snort-devel mailing list