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

[Matthew Jonkman <jonkman () emergingthreatspro com>]

On Mar 18, 2011, at 9:14 PM, Joel Esler wrote:
> > It was decided to not change the SIDs to avoid performance degradation, lack of
> > continuity in the GPL rules, etc.  So, if the VRT team makes changes to the GPL
> > rules we'd (ET [1]) appreciate the updates.  Conversely, if we (ET [1]) make
> > changes we'd like to submit these to VRT as well, and come to an agreement for
> > the sake of uniformity.
>
> I have an idea for that, but I am not going to volunteer it publically until I discuss it with Sourcefire internally 
> to make sure we can do it.  If ET would like to submit changes, I encourage them to do so.  The OSSRC was formed to 
> deal exactly with this issue, however, it seems as if not only the OSSRC has fallen off, but the communities that 
> formed it have come up with different goals.
>
> For example, detection was supposed to be unique.  However, now, there are rules that cover the same "things" in both 
> rulesets.  OSSRC was there to manage duplication of this kind of thing and the transition of rules from the ET 
> ruleset over to VRT.  It's obvious to me that isn't going to happen anymore.  Ref: ETPRO.

The ET ruleset is not intended to be an add-on for VRT anymore. It can be used that way, but we are not going to NOT 
cover an issue we have intel in on the community because VRT might put something out a week later. Sorry, that 
arrangement was over years ago. Please understand, ET Open and ET Pro are independent rulesets. We are not here to feed 
rules into the VRT ruleset, although you are perfectly free by license to take them as you like. But we are publishing 
them in more formats and versions, so if anything is to be a master repository it should be the one with the super-set 
of versions and formats. 

VRT is welcome to pull the 1 or 2 engine versions they'd like out of ours and use them commercially. They're BSD 
licensed on purpose. That would actually eliminate more duplication if VRT were to pull the rules that they like and 
then people wouldn't have to combine the open set with VRT. And that'd be perfectly file, these are BSD licensed and 
put out there for people to use commercially if they like. Hundreds of companies and projects repackage these rules and 
we love it!

So why don't we go down that road? Instead of trying to avoid duplication when people combine, why not make VRT a 
complete ruleset on it's own? Then no more combination issues and duplication.

Matt



> > [1] I should say I am a ET community participant only and have no profit to
> > derive from my participation.  I'm actually speaking presumptuously for ET, but
> > I think there's a desire in cooperation between both organizations.  Just
> > bringing you up to speed.
>
> The Snort community is a big world.  Getting a lot bigger recently (I've seen registration and traffic increase).  
> Input from all forms is good.
>
>
> --
> Joel Esler
> jesler () sourcefire.com
> http://blog.snort.org && http://blog.clamav.net
> Twitter: @snort


----------------------------------------------------
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