Snort mailing list archives
Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody?
From: Joel Esler <jesler () sourcefire com>
Date: Mon, 21 Mar 2011 16:48:20 -0400
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
Current thread:
- Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody?, (continued)
- Re: [Emerging-Sigs] GPL rules - who maintains them?Nobody? Weir, Jason (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Jeff Kell (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Matthew Jonkman (Mar 22)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Jason Wallace (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Jason Brvenik (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Joel Esler (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? waldo kitty (Mar 21)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? NA (Mar 22)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Mike Lococo (Mar 23)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Matthew Jonkman (Mar 22)
- Re: [Emerging-Sigs] GPL rules - who maintains them? Nobody? Joel Esler (Mar 21)