Re: bash sockets: printf \x0a does TCP fragmentation

[dirk+bash]

On 9/22/18 7:30 AM, Bob Proulx wrote:
> dirk+bash@testssl.sh 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