Re: Pcre Binding

[nnposter () users sourceforge net]

Hello Patrick,

Patrick Donnelly wrote:
> On Fri, Jul 11, 2014 at 2:51 PM, <nnposter () users sourceforge net> wrote:
> > The PCRE/lpeg conversion broke telnet-brute.nse. A cursory look at the
> > script code shows that some unwarranted liberties were taken when
> > re-inventing the match patterns.
>
> I'm responsible for most of the conversions from PCRE to LPeg.
> telnet-brute was the only difficult script to convert. This is largely
> because it uses some peculiar patterns like \b (word boundary) and
> some unnecessary/obscure capture options (?).

The reason behing the pattern complexity is to increase accuracy, such
as to avoid false positives.

> I had to make a fix in r33180 because I botched the patterns. I'm
> pretty sure they are correct now and we have some simple asserts to
> verify subjects that should match.

I have tested r33222. As an example, the script will report every
tried username as valid on Cisco IOS.

> > IMHO it is not appropriate to do so unless the person can in fact
> > validate that the patterns are still working as expected. Put
> > differently, either the new patterns should be functionally equal
> > or the legacy PCRE bindings should not be messed with for the time
> > being.
>
> I would normally agree with this philosophy but because we have so
> many scripts which are non-trivial to confirm actually work, I don't
> feel this is a sensible way to think.

Of course it is non-trivial to re-validate that the updated scripts
actually work and this is precisely why I believe that it is more
prudent to assume that an original script author wrote the more
complex patterns in a particular way for a good reason unless a defect
or weakness is found. With the overarching objective of making sure
that nmap works we should minimize changes that cannot be assessed.

Devin's argument for removing the PCRE functionality is that Lpeg is
a functional superset. If true, why not to simply reproduce them
accurately?

Cheers,
nnposter
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/