Re: Idea: tips of the day?

[Jacek Wielemborek <d33tah () gmail com>]

Here's a log of my conversation with Daniel:

20:05:45         d33tah $ bonsaiviking: what do you think on the nmap
tip of the day?
20:05:54       rainfyre $ bonsaiviking: oops that last reply was to you
20:06:01   bonsaiviking $ d33tah: I'm not crazy about the idea.
20:06:10         d33tah $ mhm
20:06:14              > $ exploitzen (~root@177.107.132.212) has joined
#Nmap
20:06:40   bonsaiviking $ at least not in its current form.
20:07:02              > $ psd_ (~psd@202.78.172.162) has joined #Nmap
20:07:04   bonsaiviking $ I suppose it wouldn't be too bad for Zenmap,
but I don't like cluttering up the CLI with stuff like that
20:07:32   bonsaiviking $ The major challenge, as I see it, would be
content: how to deliver it, and what's in it.
20:07:33         d33tah $ i wonder how could i make this idea better
20:07:55         d33tah $ "what's in it" doesn't sound that difficult. i
could probably think of dozens of interesting tips.
20:08:21              > $ chaisen
(~chaisen () p54993A80 dip0 t-ipconnect de) has joined #Nmap
20:08:23              < $ chaisen
(~chaisen () p54993A80 dip0 t-ipconnect de) has quit (Client Quit)
20:09:01   bonsaiviking $ d33tah: then my other thought was, what makes
this the best delivery mechanism for these tips?
20:09:29       rainfyre $ batrick: bonsaiviking that fixed it
20:09:35   bonsaiviking $ huzzah
20:09:38       rainfyre $ lol
20:09:42       rainfyre $ embarassing haha
20:10:06       rainfyre $ ah well. must be time for breakfast
20:10:07         d33tah $ bonsaiviking: the user running the command is
probably actually the user and we know (from this channel for example)
that some people don't RTFM ;)
20:10:20       rainfyre $ lol d33tah
20:10:51         d33tah $ (for years i didn't either, so the tips of the
day could be a good advertisement)
20:11:33   bonsaiviking $ d33tah: I would rather see a more unified
approach, though: Something in TOTD should be also accessible by someone
searching Google or browsing our online documentation
20:12:00         d33tah $ so we could have a TOTD section in the manual
and pull TOTDs from there?
20:13:01   bonsaiviking $ That's more along the lines I was thinking.
Like how we generate https://nmap.org/nsedoc/ from the Luadoc content in
scripts and libraries
20:13:49         d33tah $ would it make you more willing to merge such
commit or is there anything else you find broken there?
20:13:50   bonsaiviking $ Any time you remove documentation from
implementation, you make maintenance harder
20:14:37         d33tah $ i don't understand.
20:15:10   bonsaiviking $ Hmm, I had a great example of this the other
day that I needed to fix, but I didn't write it down. Let me think now...
20:16:17   bonsaiviking $ ah! http://nmap.org/book/nse-api.html
20:16:48   bonsaiviking $ The section on port.service says, "If the
port.version field is nil, Nmap has guessed the service based on the
port number"
20:17:22         d33tah $ how does that relate to TOTD?
20:17:24   bonsaiviking $ And we have lots of script code doing that
sort of check: if port.version and port.version.product == "Apache httpd"
20:17:26   bonsaiviking $ or something
20:17:43   bonsaiviking $ sorry, I'm expanding a bit: I'll bring it back
to TOTD in a sec.
20:18:06   bonsaiviking $ But in reality, port.version is never nil (in
the current version), because it's always populated
20:18:20   bonsaiviking $ So the documentation and the implementation
have diverged.
20:18:44         d33tah $ ...i think i get it now
20:18:59   bonsaiviking $ The ideal TOTD (or whatever it turns into,
because I'm not completely sold on the delivery mechanism) would...
20:19:05         d33tah $ you're suggesting that making TOTDs a separate
section in the manual would make it another place that would keep having
to be updated
20:19:33         d33tah $ so it'd be even better to have them mixed into
the relevant pieces of the documentation
20:19:36   bonsaiviking $ pull content from documentation that exists as
close to the implementation as possible.
20:20:04   bonsaiviking $ Right, at least not further fracturing the
documentation
20:20:20   bonsaiviking $ So our documentation exists as docbook XML
20:20:43   bonsaiviking $ and that gets converted by different systems
into the man page, the web site, the print book, etc.
20:21:27   bonsaiviking $ It would be ideal if there were some docbook
element like <example> that could be pulled out from the documentation
and made accessible in a searchable or randomized fashion
20:21:38         d33tah $ okay. so we have a mechanism that extracts the
TOTDs using xpath, converting them to char*[], then we pull a random
number % number of TOTDs and print the TOTD. mergeable?
20:23:09   bonsaiviking $ You're still too fixed on the --totd flag or
whatever. That implementation could be open for discussion (i.e. I would
not commit it without hearing from other devs and users first)
20:23:39   bonsaiviking $ But the idea of structuring our documentation
to allow grabbing random examples (or searchable examples!) is one I can
get behind.
20:23:59         d33tah $ i'd make it default rather than --totd
20:24:16   bonsaiviking $ Then we can have many front-ends: Zenmap, web,
nmap option, etc.
20:24:50   bonsaiviking $ I'd be more eager to see something similar
done with NSEdoc, or at least a reworking of --script-help
20:25:06   bonsaiviking $ The output is not very useful at the moment, IMO
20:25:28         d33tah $ i for one love the scanner more than the NSE ;)
20:25:57         d33tah $ i think i'll post this conversation to the
mailing list.
20:25:58   bonsaiviking $ But that's where the greatest need is for
accessible documentation. Everyone and their brother has written a "tips
and examples for using Nmap" blog post
20:26:36   bonsaiviking $ and there are fewer options (though there are
very many!) to the nmap binary than there are NSE scripts.
20:26:41         d33tah $ the problem is if they actually reach the
people. CLI could do best at it.
20:27:14   bonsaiviking $ There was a previous effort to have a NSE
script that would suggest other scripts to run based on ports and
services available.
20:27:18         d33tah $ so something like - a user runs a script and
gets a TOTD about it?
20:27:23   bonsaiviking $ ?devlist "script-suggest"
20:27:25          Nhelp $ bonsaiviking:
https://encrypted.google.com/search?q=site%3Aseclists.org+inurl%3Anmap-dev+script-suggest

Attachment: signature.asc
Description: OpenPGP digital signature

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