Re: [Rainmap] RFC: storing option descriptions (to be displayed in the UI)

[David Fifield <david () bamsoftware com>]

On Fri, Jun 18, 2010 at 05:24:10AM -0700, alexandru wrote:
> Hello all,
>
> For the new/edit scan interface I plan to take an approach similar to
> Zenmap's, in that each option has some help text that appears when the
> user hovers over/edits the option. I plan to store these settings in a
> Python file, in the following form:
>
> ___
> # Group options together by section. The code creating the user-facing form
> # looks at this mapping. It only renders sections based on these
> # components, so this is also a way to add or remove scan options.
> SECTIONS = {
>     'TARGET': [],
>     'DISCOVERY': ['-sn', '-Pn'],
>     'TECHNIQUES': [],
>     'PORTS': [],
>     'SERVICES': [],
>     'NSE': [],
>     'OS_DETECT': [],
>     'TIMING': [],
>     'EVASION': [],
>     'OUTPUT': [],
>     'MISC': [],
> }
>
> # Each feature's information is keyed by the shortopt form. This key is also
> # how we map parameters to the values parsed by NmapOptions. Code displaying
> # the form uses 'NAME' for the field label, and 'HELP' to show information to
> # the user.
> FEATURES = {
>     '-sn': {
>         'NAME': 'Ping Scan',
>         'HELP': 'Disable Port Scanning.',
>     },
>     '-Pn': {
>         'NAME': 'No Ping',
>         'HELP': 'Treat all hosts as online.',
>     },
>     # ...
> }
> ___
>
>
> I'm open to suggestions on alternate ways to define and store these
> fields. Zenmap keeps its information in a profile_editor.xml file —
> which served as partial inspiration, though David mentioned there are
> some issues with the approach.

What you're doing is fine to me. The difference with your technique and
Zenmap's is that your doesn't imply a GUI layout. Here's
profile_editor.xml:

<option option="-sA" label="ACK scan" short_desc="Send probes with ..."/>
<option_check option="-A" label="Enable all advanced/aggressive options"/>

Zenmap's database implies a GUI layout with its "option" and
"option_check", which I think is too inflexible.

Keeping the database as a Python file is a good idea. That's probably
even easier for someone to edit than XML, and detecting errors in the
file will be just as easy.

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