Bugzilla Bug 34150

flexresp support via libnet should be optional (a use flag might be overkill;
perhaps a libnet use flag would be more appropriate)?

With libnet-1.1 merged, merging snort-2.0.0 fails due to snort not liking that
version of libnet

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

I wonder if the whole flexresp functionaility shouldn't be dropped as whole
actually. It gives the user of the software a false "snort will protect me from
bad guys" sense of security, while providing zero protection in the default
setup (and most people actually do run default setups) and limited
functionallity when it is in use.

Anyway, if you think it's still a good idea to keep flexresp support in Snort
I'll add the local USE flag to the ebuild.

I'd like to hear what you guys think of this.

I wasn't planning on actually using flexresp - if you want to be a black hole
(which I do), just about the worst thing you can do is start sending ICMP
unreachables or whatever when a hostile scanner passes by.

I suppose it would be easy enough for someone with proper motivation to put the
--enable-flexresp line back into the ebuild if it came out completely...

I am preparing a updated ebuild that disables flexresp by default unless a
(local) "flexresp" USE flag has been specified.

If you have anything against this please voice out now.

Ok, commited snort-2.0.5-r1:

  - Made flexresp optional (controlled by "flexresp" local USE flag)
  - Made smbalert optional (controlled by "samba" USE flag).
  - Threading support was never officially supported in Snort, and has
    been removed from ebuild now as the code is, if not already has been,
    cleaned from the source tree.
  - Updated prelude patch.
  - Assigned myself as the primary maintainer of this ebuild, with the
    hardened as the herd.