[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: LuaSocket: No way to protect against fuzzing attacks?
- From: HyperHacker <hyperhacker@...>
- Date: Tue, 11 Oct 2011 23:36:24 -0600
On Tue, Oct 11, 2011 at 18:25, Sam Roberts <firstname.lastname@example.org> wrote:
> On Tue, Oct 11, 2011 at 4:25 PM, Dean Sellers <email@example.com> wrote:
>> I did notice the partial result return, but like HyperHacker, I couldn't
>> make it work reliably. Sometimes I would get no partial result?
> Never seen that, but I remain interested to know if somebody can show
> me a reproduction.
>> As you point out though for this protocol byte by byte makes sense, in
>> fact this protocol was originally designed as a serial line one. That is
>> probably why it seems similar.
> What's the protocol?
>> One of my jobs (in the near future) is to add serial support to the lua
>> API I am writing, so if you are willing to share I would love to see
>> your implementation :-)
> Code is based off unix.c, too bad there isn't a better way to avoid
> the code duplication, but
> I don't want to disturb the luasocket code base too much, I still have
> hopes Diego will merge at least the obvious
> bug fixes, if not the features.
> Using a serial device also requires setting its modes, for that I have
> bindings to termios, that I should be able
> to put up on github, too. Of course, you can always set those with stty.
I can't seem to reproduce the missing-last-bytes issue except in my
server, which is rather large and complex for a testcase and is using
threading and the acceptfd patch. (I did test acceptfd in a smaller
script as well.) Who knows why that's happening.
Anyway using *l I do get the partial result after the 'timeout'
message, so it looks like it is possible (although a bit ugly) to
buffer lines in my own applications and reject them if they're too
long (or too numerous, or arriving too slowly, etc). Thanks for
pointing that out (whomever did that!) :-)
Sent from my toaster.