Re: Script selection interface - Update

[David Fifield <david () bamsoftware com>]

On Tue, May 25, 2010 at 07:34:58PM +0530, kirubakaran S wrote:
> I have given link to my final mock interface[0]

I like this. I think you need to make the link more prominent so people
can find it easily, so here it is again:

http://docs.google.com/View?id=dwn8dz7_51cz637bg7

> > Before you start implementing this, I want you to do the review of NSE
> > Facilitator and OpenVAS-Client. It is best to see what others have done
> > and how it can be improved.
> Hi,
> I reviewed OpenVAS. They call scripts as plugins. OpenVAS  organised
> plugins into group of Families. We call it category in nmap.Unlike
> nmap,in OpenVAS a plugin can present in only one family.
>
> I found the following things interesting about openVAS.
>
> ** Filtering Feature : OpenVAS filters plugins according to pattern
> supplied by user. The pattern is applied on various attributes of
> plugins. The attributes on which the pattern is  to supplied are
> selected by user.

This is a nice feature. I'm trying to decide if we need a separate
filter language, or if we should limit it to the filter already
supported by NSE, strings like "(default or vuln) and not intrusive".
Using our existing filter language is nice from the point of view of
doing live update with the command line. However I can also see wanting
to do a fulltext search on the script descriptions.

> ** Plugin MetaData : Plugin metadata are presented to user in a
> separate dialog box, when the user double-clicks the particular
> plugin.

I think this is a reasonable design decision, when there's extra
information that doesn't need to be shown all the time. Your proposed
NSEDoc links work like this, actually.

> ** Check box is given to each script so whenever the user wants to
> select the script. They can simply check the check box and supply the
> arguments.

I've got some ideas on shwoing which scripts are selected below.

> > Regarding this one, I think we only need the most important fields.
> > I'd suggest a link to the script's NSEDoc page for people to get
> > "license" and "author" field values.
>
> ** The Reason I have given link to NSEDoc instead of showing all the
> metadata is that, it will eat up more space and leaves less space for
> arguments.

The NSEDoc link is a good idea. I think it's important to show the
entire script description (several paragraphs) on this page. That's easy
enough to put in a scrolling text field. I think I agree with Fyodor
that we can leave out the author and license fields. Or just append that
data to the end of the text field, so people can see it by scrolling
down.

> ** It is difficult to remove Help section Because it will affect all
> other tabs.Help is a text viewer already packed in to the window.

I don't care if it's difficult. Let's design a good interface, and then
write to code to make it happen. If it turns out to be too hard, then
we'll forget it. But don't let presumed implementation difficulties
limit your vision.

Anyway, I don't think it will be that hard to remove the help box from
this tab, or change its shape to fit the interface better. I would much
rather use up 25% of the space on a bigger description text box.

You are going to have to deal with space for arguments anyway, because
there's no limit to the number of arguments that a script can have. I
want you to design the interface for a script with 20 arguments. For
that you will need to use scrolling or a popup box or something.

> ** I haven't included check box for each of the script.My interface
> designer don't have that option.I am planning to provide that in real
> interface.

That's a good thing to bring up, how we're going to show which scripts
are selected out of the master list of scripts. We could highlight or
checkbox the specific scripts, but that will get annoying when you have
to scroll up and down to see which scripts you've selected. Of course in
the final interface, the command line will always reflect the scripts
you've chosen, so at least there's a clue there. We could have another
box listing just the selected scripts (this could double as a preview of
scripts that will run with a specification like "http-*"). I dislike the
interfaces where there are two boxes with → ← arrows between them, and
anyway that doesn't fit well with the requirement that we have to get a
list of scripts from a typed specification.

Let me give you an example of what I'm thinking of with regard to the
specification parsing. If you enter "vuln" in the command line, it
should somehow list all the vuln scripts, indicating that they will be
run. Then if you click one of those, say http-enum, and remove it, the
interface would update the specification to read
        "vuln and not http-enum"

David Fifield
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/