Re: Nsock read buffer

[Patrick Donnelly <batrick () batbytes com>]

Hi David,

Let me first say this is an excellent change and I'm happy to see it
is nearly done. Thanks for your hard work on this.

On Tue, Jan 11, 2011 at 11:57 PM, David Fifield <david () bamsoftware com> wrote:
> Another question is what to do with sanity byte limits. We can't just
> read forever if someone keeps writing without sending a newline. Current
> nsock_readlines already has such a limit, only it is an undocumented,
> unspecified internal constant. If there's no newline you get back a
> partial line. An alternative is just to return an error and not violate
> the contract that we will return only the requested number of lines.

I think we could solve the reading new line problem with a slight
change to the API. If the nsock_readlines function were to return
partially read data via the callback but signal it is not done reading
("buffer is full, hold onto this until I'm done") then we can leave
policy up to the caller. In particular, we could have the nsock
binding for NSE just hold onto the string and repeatedly concatenate.
Handling abusive cases where all the memory is being eaten up is still
tricky but is no longer an nsock problem. NSE could throw a regular
Lua error and call it a day when memory is exhausted.

This may be too complicated though...


Also, since this reply is so late, I'm wondering what the status is on this?

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