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

[Joel Esler <jesler () sourcefire com>]

On Mon, Mar 21, 2011 at 3:53 PM, Matthew Jonkman <
jonkman () emergingthreatspro com> wrote:

> On Mar 21, 2011, at 10:43 AM, Joel Esler wrote:

>    - 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.
>
>
> They're downloadable at http://rules.emergingthreats.net/
>
> We have many versions, and suricata as well. Pick which you'd like to diff
> from. Thanks Joel!

Again, if changes have been made to GPL rules then the changes should be
submitted back to the maintainers of the ruleset that authored them.  In the
form of a patch, or a rules file would be good.   That's the way open source
projects usually work.   When I've suggested changes to your rules, I've
done it on your lists.

But in the meantime, I took a cursory look at the differences.  It's very
difficult as the rulesets aren't split up, you've renamed the MSG, changed
the rule options, but not the SIDs.  I see you've even copied our DELETED
ruleset.  I've grepped that out, since, well, they were deleted.

I count about 234 differences in detection in the 2.9.0 ruleset, and there
should be far far less in the older ones.  Mostly fast_pattern and http
keyword differences.  I know we've added references to the GPL rules, so
there are significant differences, some in metadata, some in detection, but
this is where I suggest a patch be suggested back, so that someone can
maintain them properly.  If we have put them out as a separate set, we can
look at that as an option.  That solves all the problems (save your Suricata
ruleset problem, but.. not much I can do there).


>    - 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.
>
> We're not duplicating though, we're just modifying. But what seems to be
> the core issue is that we will have versions and platforms that are not
> supported by SF, so why would we send the changes to those (suricata, or
> snort 2.8.6 for example) to SF for inclusion there? We need to maintain our
> own versions, and I don't expect we'll have a lot of overlap.

I disagree, you *are* duplicating.  The SIDs are the same.  The SIDs that
are assigned to the official ruleset, your group has taken and modified.  As
Nigel said, the correct way to go about this is to duplicate the rule and
re-number it.  If you'd like to submit changes back to the original ruleset,
please free to do so.  I don't know how else to say this.  I doubt there
will be any changes to 2.8.6 versions of GPL rules.  As for Suricata, you
are going to have to maintain that ruleset on your own anyway.  It makes
sense to re-sid them then.  I know your rule language is essentially ours,
with minor differences in protocol detection and what not (from what I have
seen).



> I'm still anti re-sid'ing. We lose a lot of history there and reference.
> But if the sentiment of the community goes there we can make that happen.
> But I think we have other issues to solve then, like deduplication for folks
> that still combine the et open rules with vrt. It'd be a week or more of
> work to re-sid and update, so we'd probably not have a contiguous range of
> sids.
Seems as if there is a split decision.  I know *you* are anti doing it, but
it looks as if the majority of the people who have responded to this thread
prefer the re-numbering.  As many others have said, let the users deal with
the fact that there are two, or let the tools do it.  As Jeff or Jason said,
maybe a grep for GPL to turn yours on of off is an easy enough solution.
 Let the analyst decide.


> 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 realize I may be pessimistic, but it's been nearly 10 years of that now.
> I don't feel like we've gotten many of the things you and I and the
> community have wanted to do approved or off the ground. So I'm quite
> pessimistic I'm sure. But not against things moving along if they might....

Well how about we set aside the ~6 years of bickering now that someone else
is coordinating the efforts?  Don't push back before we've even started.
 I've been trying to reach out and reach out for the past "x" number of
months, and received nothing but negativity.


> 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.
>
>
> No insult intended, and apologies if it was taken that way. My comments
> earlier were based on what we see. And since we can see very little there is
> a lot of assumption in there. More openness would go a long way.
If you have questions ask.  I'll answer.  It's impossible for me to know
what you want to know, I'll answer any question I can, if I can.

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.
>
>
> I don't think I said that, and wouldn't. You've been the best hope we;ve
> had for a very long time to make collaboration work!!
Then work with me.  I consider this the first hurtle in many.  But as far as
what needs to be done, we can't have duplication in SIDs.  So, I am not sure
how you want to fix it, there's been several suggestions, but one needs to
be done.  We can't have ET duplicating SIDs that are already out there.


-- 
Joel Esler | http://blog.snort.org | http://vrt-blog.snort.org |
http://blog.clamav.net

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar

_______________________________________________
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