[Snort-devel] Snort as a library
Michael.Richardson at ...2449...
Tue Jul 20 14:07:33 EDT 2004
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Daniel" == Daniel Roelker <droelker at ...402...> writes:
Daniel> Again, this patch doesn't affect functionality and is not a
Daniel> security issue, so it's still in the queue of submitted
Daniel> patches. I'm not saying that this type of checking isn't
Daniel> valid, but I am saying that there are higher priority
Daniel> patches that we are looking at.
Yeah, but there is an order of operations issue here, because once
you turn on -Werror, you have to revise other things. On the other hand,
if you apply other things first, then you have to revise -Werror.
Except that you can apply all of the patches that involve code that
is not affected by the other queued patches as soon as you like.
If you can give me an idea when you want to integrate the -Werror
patch, I will revise it for whatever code is in HEAD.
Daniel> Just to give everyone an idea, we're still reviewing the
Daniel> massive wireless patch and we are pretty excited about it.
Daniel> In addition, we just got sp_respond2 (with libdnet) from
Could you make your patch queue public?
That would be very useful to everyone involved.
Daniel> However, my main concern about adding this patch was that
Daniel> there was no clear game plan for what you were doing. You
Daniel> had eluded that this patch could be used for adding multiple
Daniel> interface functionality, but this was the first time that I
Daniel> had heard about this from you.
The goal is to be able to port various pieces of snort to an embedded
processor that connects to a piece of hardware that does TCP reassembly.
The system is a PCI-X card that plugs into a Linux host.
Our game plan is to:
1) make snort more modular, such that there are few or no
globals. This means passing a number of things around as
parameters. The exact split between PV and TV changed four
times as I was working on it. I expect it to change some more.
2) better split between generation of logging/alerts and recording
of them. I think that this is mostly all done, but I found a
number of difficult places, particularly with calls to pcap
functions for the pcap logger.
Basically, all of the recording functions need to be abstracted
so that they can go over inter-processor IPC.
Based upon the need for barnyard and friends for high speed
logging, I think that making this more streamlined would be
3) splitting up processing of configuration files from collecting
This isn't a huge task either --- it is mostly already done,
but there are some corner cases that we think we can fix.
4) offload of TCP-reassembly function from layer 5-7 searching.
This might not be of general interest. The layer 2-4 code is
clearly of great value, since there are lots of attacks at that
level as well.
Daniel> may not be the same changes that you would make. We do try
Daniel> to clean up code when we can, believe it or not, and adding
Daniel> this feature would give us a good chance to revamp our
Daniel> initialization code and variables. So most likely, the
Daniel> changes we would make would be completely different, since
Daniel> you just took the existing initialization code and put it
Daniel> into structure form.
Yes, I did.
It wasn't because I was lazy -- but because I wanted to make sure that
the change had as few conceptual changes as possible. Once the major
"change" is done, moving stuff around again is actually quite easy. XP
Daniel> And as a developer, I always ask for requirements and design
Daniel> first before we even start writing code, whether it be
Daniel> structural or functional. Multi-interface sniffing is a
Daniel> substantial feature and we are not going to just take a
Daniel> first time contributor's patch that changes core code and
Daniel> add it into our repository because they say it works fine
Daniel> against their test suite.
Please publish your test suite.
Daniel> Brian Caswell is the best person to explain what this
Daniel> testing scheme is covering, perhaps he can respond here or
Daniel> you can mail him directly?
I look forward to having him explain what your test suite is doing.
I understand how critical it is --- I would never dream of submitting
patches without test cases, when there is a test case system.
] ON HUMILITY: to err is human. To moo, bovine. [
] Michael Richardson, Seaway Networks Corporation [
] michael at ...2449... http://www.seawaynetworks.com/ [
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Finger me for keys
-----END PGP SIGNATURE-----
More information about the Snort-devel