Re: Ncat + Lua - GSOC feedback request

[Jacek Wielemborek <wielemborekj1 () gmail com>]

2013/6/17 David Fifield <david () bamsoftware com>:
> On Sun, Jun 16, 2013 at 11:58:28AM +0200, Jacek Wielemborek wrote:
> > On Fri, June 14, 2013 at 10:43:42 David Fifield wrote:
> > > lua-exec option.
> >
> > I like this idea as a starting point - I understand that all the the calls to
> > io.write()/print() should direct to the socket instead of the stdout and all
> > calls to io.read() should read from the string? (oh, by the way, is the
> > forking really necessary?)
>
> Forking a subprocess is the right way to do this. If you're finding
> yourself modifying or redirecting specific functions like io.write to do
> something with a socket, you're doing it wrong and breaking abstraction
> barriers. io.write should write to stdout and io.read should read from
> stdin. Redirection is handled by the parent Ncat process. The subprocess
> should literally just call dofile on the file name you give it. Look at
> the netrun function for how this should work. Note that there are two
> implementations of netrun, for POSIX and for Windows.

Yeah, I noticed that when I started coding (the code's in the repo BTW). For
my comments on the Windows implementation, please refer to my report #2 (not
saying I'm not going to do this, but I'd definitely put this off for later).

> > > Implement telnet negotiation and CRLF replacement.
> >
> > I'll look into that, at the moment I don't really know much about the
> > negotiation protocol (but I'll catch up). I'm a bit worried about hardcoding
> > Lua code in the Ncat core though - what if the user wants to drop Lua
> > functionality? Fallback to C routines? Or should we make Lua a requirement for
> > Ncat to compile?
>
> That's a good point about not requiring Lua for compilation. What I'm
> saying is that trading the syntax
>         ncat -t
> for something like
>         ncat --lua-script telnet.lua
> is bad. Lua code could be used internally to do some of the things we do
> now with code in the middle of read/write loops. On the other hand, C
> code could also be used to do that, with better factoring of the main
> program.

Sounds like we're heading for the plugin system Daniel Miller suggested. I
have to admit I'm excited about it!

> > > WebSocket mode. See RFC 6455. It would be nice to do
> > >     ncat --websocket ws://example.com:8000/
> > >     ncat --listen --websocket ws://localhost:8000/
> >
> > I love this one - it would add some really new functionality to Ncat and be a
> > great demo of what the Lua engine could (and should) be be capable of. The
> > only thing that I don't exactly understand is the usage
>
> Don't worry about the usage. This is a use case, not an implementation
> specification. Just think about whether your proposed implementation
> will make this kind of use possible.
>
> > ncat --lua-exec "websocket,url=ws://example.com:8000,mode=listen"
>
> However, I will definitely veto command-line syntax like this. Why
> should someone wanting to set up a WebSocket server care that it is
> implemented in Lua? Why trade --listen for mode=listen? For the user,
> the decision to connect using WebSocket shouldn't look a lot different
> than the decision to connect over SCTP.
>
> A good rule of thumb: The word "lua" should not appear in any command
> line that is just using WebSocket.
>
> David Fifield


I like the approach, never thought of command-line design that way. It seems
to me that the second Lua functionality is starting to form - some --lua-run
or something like that, that runs a script and has API access to the struct
options, which it parses on its own. Or some special mode-specific functions so
that the websocket script would split the script into:

function connect_mode()
        do_stuff()
end

function listen_mode()
        do_other_stuff()
end
_______________________________________________
Sent through the dev mailing list
http://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/