On Samstag, 27. Februar 2010, Dražen Popović wrote:
> I am aware of the fact that NASL lacks certain capabilities, such as OO
> paradigm, various high level data types. Sure that this kind of
> extensions to NASL would mean a great deal to NASL developers to make
> state of the art scripts. But lets do the best with what we've got, and
> if the time comes for NASL to evolve in such a way, c00l.
> Answer to your question...definitely!
>
> To that point, I wish to state that there is a need for introducing
> certain design guidelines, patterns for "inc" development. The purpose
> of which is, of course, better code quality and speed up of plugin
> production. Let me demonstrate my thoughts with a brief example:
>
> Consider the SMB protocol...First I would implement a smb-packet.inc. In
> this inc you could find "build_" and "dissect_" methods for easy SMB
> packet crafting (like in Perl::Net). This "-packet.inc"s would represent
> a ground for protocol operations implementation, also if making some
> exploit on that particular level the creation of vuln packet would be
> easy and nice. The next step is to implement the actual protocol in a
> "smb.inc". As said before, this inc would include("smb-packet.inc") and
> would heavily rely on that particular inc. Here you could find protocol
> specific methods which provide a adequate abstraction level for the
> programmer/user.
>
> This is just a rough outline. Also we should consider naming
> conventions, which data types to use etc..
>
> I've looked how other languages do it, and sure they have an advantage
> (OOP), but I don't see why we can't make NASL even better. :)
>
> Your opinions?
"Making NASL better" in the form of further/cleaned/optimized .inc's
or in the form of powerful extended API (built-in functions) is very welcome
from my point of view!
About more language structures I am unsure in how much gain
can be achieved. This should only be done for a real win as it
needs a good expert and quite some testing to have stable extensions.
However, as a base rule: the more generic the extensions the better
because the Feed can't easily be changed to new elements while
out there are many older OpenVAS scanners in operation.
Best
Jan
--
Dr. Jan-Oliver Wagner | ++49-541-335084-0 | http://www.greenbone.net/
Greenbone Networks GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B
202460
Geschäftsführer: Lukas Grunwald, Dr. Jan-Oliver Wagner
_______________________________________________
Openvas-plugins mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
