[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bash sockets: printf \x0a does TCP fragmentation

From: dirk+bash
Subject: Re: bash sockets: printf \x0a does TCP fragmentation
Date: Sat, 22 Sep 2018 11:50:17 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0

On 9/22/18 7:30 AM, Bob Proulx wrote:
> address@hidden wrote:
>> we discovered a strange phenomenon in the project testssl.sh:
> You are doing something that is quite unusual.  You are using a shell
> script direction on a TCP socket.  That isn't very common.  

Do you think there should be a paragraph NOT COMMON where bash sockets
should rather belong to?

> More
> typically one would use a C program instead.  So it isn't surprising
> that you are finding interactions that are not well known.

Bob, my intention was not to discuss program languages and what is typical
with you or anybody else here.

>> printf -- "$data" >&5 2>/dev/null
> Why is stderr discarded?  That is almost always bad because it
> discards any errors that might occur.  You probably shouldn't do this.>
> What happens if $data contains % format strings?  What happens if the
> format contains a sequence such as \c?  This looks problematic.  This
> is not a safe programming proctice.

I doubt you can judge on this by just looking at a single line
of code -- the project has > 18k LoC in bash.

Github is the place to discuss and do PRs for our project.

>> If there's a workaround, please let me know. (tried to add "%b" with no
>> effect). Otherwise I believe it's a bug.
> You can re-block the output stream using other tools such as 'cat' or
> 'dd'.  Since you are concerned about block size then perhaps dd is the
> better of the two.
>   | cat

cat has a problem with binary chars, right? And: see below.

> Or probably better:
>   | dd status=none bs=1M
> Or use whatever block size you wish.  The 'dd' program will read the
> input into its buffer and then output that block of data all in one
> write(2).  That seems to be what you are wanting.

We actually use dd to read from the socket. Of course we could use
writing to it as well -- at a certain point of time.

Still, a prerequisite would be that printf is the culprit and not
how bash + libs do sockets.

> P.S. You can possibly use the 'stdbuf' command to control the output
> buffering depending upon the program.
>   info stdbuf

That could be an option, thanks. Need to check though whether

a) it doesn't fragment then -- not sure while reading it
b) it's per default available on every platform supported by testssl.sh.

Cheers, Dirk

reply via email to

[Prev in Thread] Current Thread [Next in Thread]