Re: nasl output format / nbe parsing

>What about iterating over the description and pulling out key/value
>pairs matching, like this:

> # $line is a line of input from an NBE file.
> @fields =3D split(/\|/, $line);
> if ($fields[0] eq 'results') {
>   $desc =3D $fields[6];
>     $keypat =3D qr/(Synopsis|Description|See also|Solution|Risk
>factor|Plugin output|BID|CVE|Other references)/i;

>    while ($desc =3D~ /($keypat)\s*:\s*(.+?)(?=3D($keypat|$))/gm) {
>      print $1, " =3D ", $3, "\n\n";
>    }
>  }

I think you meant to write:
print $1, " =3D ", $2, "\n\n";

But that aside, this is very similar to what I was thinking about
changing my script to but I think it would make your parsing routine a
somewhat slower.

Also, my end goal is to store each matched pattern to a specific
variable (ie the synopsis test is stored in $synopsis, etc) which I
will then use to insert the value into a database.  This means foreach
$keypat matched I will have to do a 'lookup' on $1 to see what
corresponding variable I want to store the $2 match in.  While this is
certainly doable, it would require two nested while loops to find a
match and then store it appropriately.  Of course if any new fields
are added to the $desc body, your time spent parsing will grow
exponentially.

In the real world with our wonderful high powered machines this
shouldn't be a big problem, but I think it's clear that a static,
unchanging format would be both simpler to understand and somewhat
faster to parse.

>[NB: Perl mongers can probably suggest another alternative involving
>some module from CPAN.] You'll probably need to tweak $keypat somewhat
>more as the descriptions are, as you note, currently unstandardized.

I checked out some of the CPAN modules, and in my very short overview
it didn't look like they had the granular level of parsing that we're
talking about.

>We've been using a standard format for all new plugins since October or
>so; eg, take a look at mailenable_imap_rename_dos.nasl. This will almost
>certainly, though, be a long-term rather than short-term solution given
>the number of existing plugins that must be revised.

I agree.  I was trying to think of a writing a script to parse the
nasl files and find the ones that have "non standard" output format.=20
No matter how you look at it, I think they will be somewhat unpleasant
to fix and may require hands on attention to fix.  I suppose you could
 make the script find the output irregularities and then actually
automatically rewrite the nasl
in the correct format, but that doesn't sound like a whole lot of fun
to me and may not be feasible.

>George

Thanks for your comments.  I think I may rewrite my parser along the
lines of what you suggested above and then compare the performance for
sheer geekiness.  It might be interesting.


Matt Van Mater
_______________________________________________
Nessus-devel mailing list
[email protected]
http://mail.nessus.org/mailman/listinfo/nessus-devel