Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody?

[Matthew Jonkman <jonkman () emergingthreatspro com>]

All reasonable options, but we still have the core issue, that ET will maintain many older versions back, and for other 
platforms (suricata, and others to come). 

So staying in sync will be an issue if VRT is the master record of the rules. So perhaps our only option is to 
completely fork. But then I still don't feel we need to re-sid since the original intent will still be the same for 
each signature. So the references will still apply, and I don't think we'll have collision issues as we distribute 
rulesets with and without. 

There are issues going either way I suppose. Will have to think it over a bit.

Matt



On Mar 21, 2011, at 11:26 AM, Martin Roesch wrote:

> Ok, just my $0.02 here.
>
> > From my viewpoint we have a few pretty simple options:
>
> 1) ET forks the GPL rules and maintains/distributes their own set.  In
> this case they should take new SIDs because we don't want to have
> inconsistency in what is being detected for a given SID number.  This
> would cause havoc in any automated event processing backend and should
> be avoided at all costs.
>
> 2) ET maintains a patch set against the GPL rules that people can
> download/apply as needed.  As part of this patch set they should
> probably be renumbered unless the patch is accepted into the canonical
> set maintained by Sourcefire.  We do something similar in our
> commercial product when a user elects to modify an existing (VRT)
> rule.  We renumber the rule into "userland" SID-space and the editing
> continues from there.  This is done to avoid disrupting backend
> processing both in our and other's event processing systems.
>
> 3) ET distributes the unmodified GPL rules.  Apart from
> "one-stop-shopping" I don't see a lot of need for this.
>
> 4) ET develops their own rules that cover detection of the same things
> that the GPL detects in their own SID-space.  Apart from the
> unnecessary duplication of effort and inefficiency in the detection
> engine this would work.
>
> Am I missing a case here?
>
> Marty
>
>
> On Mon, Mar 21, 2011 at 10:43 AM, Joel Esler <jesler () sourcefire com> wrote:
> > Okay --
> > I've say back some of this discussion to see how it would pan out.  But I
> > feel as if this has gone on long enough without input, not saying I'm
> > cutting it short, but....  Let me sum up everything as I see it, and
> > hopefully we can fix the whole issue.
> >
> > I haven't diff'ed your version of the gpl rules to ours, I'll try and make
> > time to do that today if I can -- and I haven't diffed our gpl rules from
> > 2005 to now (3464 and below), but I suspect they haven't changed much maybe
> > some references and what not, but I'd like to see what else.
> > I have a couple ideas that I have discussed with Sourcefire internally, and
> > I'm not going to talk about those until they come out.  I don't want to say
> > "here's my idea" and then have someone print it out and staple it to a wall.
> >  (evilghost -- ;).
> > I'd like the maintainers of the ET GPL rules to please send me any changes
> > that you have made to the rules that we could incorporate, as that has not
> > been done yet, and it should be.
> > I'd like the maintainers of the ET GPL rules, if you insist on keeping the
> > GPL rules, please fork them, re-sid them, and add a reference back to the
> > original SID.  Please do not duplicate the SIDS that are already assigned.
> >  That's the major point of this whole thread.  To avoid this whole thread
> > from occurring again.
> > If we are going to coexist, (ET and VRT) then this is the way it must be.
> >  We are a community.  We are acting like one, we will have our fights and
> > our disagreements, that's fine.  But let's make them constructive.
> >
> > On a personal note, I've tried to reach out heavily to you Matt both on list
> > and privately to try and unify the communities, you go your way with PRO
> > sigs and we go our way with PRO sigs.  But meet in the middle somewhere.
> >  I've received zero push back from Sourcefire on this, and I've received
> > nothing but "I don't believe you", "It hasn't worked before", etc from your
> > side.
> > I do feel a bit insulted that you'd insult me or Jason's integrity or
> > "community spirit" (as that's my job), and even more insulted that anyone
> > would insult the VRT.  They are a very hardworking group of individuals, and
> > no one understands what goes on in that group if you aren't inside.  On
> > purpose.  Are we going to open that kimono a bit?  I hope so.
> > I'm not asking for an apology, this is my job.  To have these discussions
> > and come up with a solution that is best for the community.  I have a couple
> > ideas that may or may not work, and that's fine either way.  If they don't
> > work, then we'll keep going the way we have been going.  If they do work,
> > then we'll have a closer community.  But please don't say that I have no
> > community spirit or aren't working to unify it.
> > Would I like to have a healthy working relationship between ET, the VRT, and
> > the community?  Yes.
> > I do not presume to speak for VRT, but I am sure a healthy community is also
> > in their interests as well.  Do I think we have a dysfunctional marriage
> > right now?  Yes.
> > Do I think we can fix it?  Yes.
> >
> > Thanks,
> > Joel
> > ------------------------------------------------------------------------------
> > Colocation vs. Managed Hosting
> > A question and answer guide to determining the best fit
> > for your organization - today and in the future.
> > http://p.sf.net/sfu/internap-sfd2d
> > _______________________________________________
> > Snort-users mailing list
> > Snort-users () lists sourceforge net
> > Go to this URL to change user options or unsubscribe:
> > https://lists.sourceforge.net/lists/listinfo/snort-users
> > Snort-users list archive:
> > http://www.geocrawler.com/redir-sf.php3?list=snort-users
>
>
>
> -- 
> Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616
> Sourcefire - Security for the Real World - http://www.sourcefire.com
> Snort: Open Source IDP - http://www.snort.org
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs () emergingthreats net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
>
> Support Emerging Threats! Subscribe to Emerging Threats Pro http://www.emergingthreatspro.com
> The ONLY place to get complete premium rulesets for Snort 2.4.0 through Current!


----------------------------------------------------
Matthew Jonkman
Emergingthreats.net
Emerging Threats Pro
Open Information Security Foundation (OISF)
Phone 765-807-8630 x110
Fax 312-264-0205
http://www.emergingthreatspro.com
http://www.openinfosecfoundation.org
----------------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc




------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users