Sorry about the top post but I am not responding to anyone just starting
out another idea.
# Rules Repo #########################################################
I don't think this should be a either or; rather I suggest we do both:
Rules/decoders should be in their own repo for management and keeping
things sane and the process simpler.
We should still ship a releases with a cultivated and well thought out
rules set that is tested and covers the largest number of users. To make
sure that we keep things in sync and working we should make sure that
all pull requests to the rules/decoders work with the current release
and with the last 1 release version. This could be done with travis-ci
and some configurations.
This idea would need a lot more flushing out to make work, but I think
it's doable.
# Rule ID ###########################################################
No matter what we do its hard and something that is just gonna take
grunt work and making sure pull requests to rules/decoders include
updates to the correct allocations files. We might want to script
something up to check with travis-ci?
-Jeremy Rossi
* Vic Hargrave <[email protected]> [2014-03-20 17:30:40 -0700]:
Perhaps there is a compromise here. How about we leave in the rules that are
enabled by default and remove the ones that are not. I can put the latter set
into the ossec-rules repository along with my hadoop rules. I think that is a
gentle way to start this and will give us time to think of better - and most
likely more complex - way later as we explore this.
On Mar 20, 2014, at 5:11 PM, dan (ddp) <[email protected]> wrote:
On Mar 20, 2014 8:09 PM, "Alberto Mijares" <[email protected]> wrote:
>
> On Thu, Mar 20, 2014 at 7:27 PM, Vic Hargrave <[email protected]> wrote:
> > Is the community in full agreement over dropping the rules from the
> > ossec-hids package? I for one don't think it is a good idea and would
> > create work to rip them out. Why not start out simple and add complexity
> > gradually? I'm also more in favor of having a base set of rules so that
> > OSSEC does something right out of the box.
> >
>
>
> Hi, I'm new in the group. Don't know if it is intended for users or
> developers only. Anyway, if my word counts, I think the basic rules
All opinions are appreciated. :)
> must stay in the package, so it can work out-of-the-box, like Vic
> said.
>
> A rules repo is a great idea. It just must be seen like an add-on, not
> a requirement.
>
>
I think having to go to multiple locations to get a decent ruleset is not good.
I think the rules should be in 1 place. It's easier.
> Alberto Mijares
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
"ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
--
---
You received this message because you are subscribed to the Google Groups
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
---
You received this message because you are subscribed to the Google Groups
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
--
---
You received this message because you are subscribed to the Google Groups "ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
