First at all. I am for coding in PERL as secondary language for OSSEC as it is almost possible to run it anywhere.
I have a cutomer that needed multiple libraries and their servers were offline and including them were not an option. Then I used PAR on a same architecture building server and copied the binaries. So PERL could be a great tool to work with ossec.
I you read the tutorial for OSSEC 2 BASE and compile rules you will see my PERL code in OSSEC.
I see your contribution as a great thing. I do believe that OSS development is ruled by meritocracy and not how long do you hang in a project. I see the whole community contribution to OSSEC is helping out. Wiki is less than a month old and it is helping to do more and better in less time that we were able before.
May be we can work togheter on OSSEC PERL projects.
AFAIK, it's still not. The config2xml tool (and the oncoming
xml2config) is for the "lay-user" who would rather look at a traditional
style config. It is separate from the mainstream development of ossec,
and is in no way meant to divert the direction of the overall tool.
It's like the little dog in the cartoons running circles around the big
bulldog yelping "What are we going to do today, Butch?"
if you use it for user interaction is ok, just do not put it as part of the init script. cause then it will be a
system requirement.
On a more specific note, the only module I used in config2xml was
Getopt::Std, which has been included in the base perl package since *at
least* perl v5.6, and likely long before. "Cleaner" code might include
the "require 5.006;" statement, which would exit if an earlier perl
version was being used. I supposed it could be rewritten in shell, but
for pure Borne compatibility, it would be an *ugly* script - ignoring
the fact that it would require non-shell binaries that aren't guaranteed
to exist, or be the right version, on the target system.