Re: bash sockets: printf \x0a does TCP fragmentation

[Dirk Wetter]

On 9/25/18 2:15 PM, L A Walsh wrote:
> 
> 
> On 9/24/2018 6:05 AM, Greg Wooledge wrote:
>> On Sat, Sep 22, 2018 at 11:50:17AM +0200, dirk+bash@testssl.sh wrote:
>>  
>>> On 9/22/18 7:30 AM, Bob Proulx wrote:
>>>    
>>>> dirk+bash@testssl.sh wrote:
>>>>      
>>>>> printf -- "$data" >&5 2>/dev/null
>>>>>         
>>>> 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.
>>>>       
>>
>> Looking ONLY at this one line, there is an obvious bug, which Bob has
>> pointed out.  It should be
>>
>> printf %s "$data" >&5 2>/dev/null
>>   
> ----
>    This brings to mind a consideration:
> As %s says to print a string of data (presumably not
> including a NUL byte), 

it certainly does contain a null byte, and every other chars
between 1-255. That's the point of a network socket.

Also "$data" will NEVER contain user input in any way
with one exception being the hostname which is transferred
via hexdump into exactly this format.

Other than that "$data" is populated purely internally. It can't
contain anything else between '\x00' and '\xff' unless there's a
coding error which could be a good idea to catch before
and not here.

This is why I said you can't look only at one line of
code.

Code reviews requires to see the whole picture.

BTW: printf seems to be off the table. BSDish /usr/bin/printf
is completely different compared to the the coreutils incarnation.
OpenBSD has per default not even a printf outside bash.

> then what happens if "$data" is
> a paragraph of text with embedded newlines.  In that case,
> it sounds like bash might break apart the single printf
> output into smaller packets rather than transmitting the
> entirety of "$data" in 1 write (presuming it is less than
> the maximum data size for a network packet).

yup.

Wonder why the coreutils printf behaves (in my sense) better
than the bash-builtin.

>    Also, if you want to flush the data out at the end, it seems
> "%s\n" would be required to force out the last line of text if
> it wasn't nl terminated.
> 
>> That is utterly horrifying.
>>   

I take that as a compliment :-)

> ---
>    Hmmm....I didn't realize how sensitive some sensibilities were...
> :-)

LOL

There are JavaScript frameworks in the browser of similar size or
even bigger, the kernel I am using right now is written in a language
which is not known to be safe and whose parser after 25 years throws
sometimes utterly misleading errors -- which still remind me on the
first K+R c compilers -- this and other things I found rather horrifying.

Script languages have long evolved -- you should take this really as a 
compliment --
and as I started this project I never thought it would boldly go there :-)

Cheers, Dirk