Re: [PATCH] Use O_BINARY to detect whether to pass "rb" to popen

On 05/22/15 08:45, Filipe Brandenburger wrote:
> On Fri, May 22, 2015 at 8:32 AM, Bruce Korb <[email protected]> wrote:
>> And, yes, the patch included a non-related issue.  Someone came up
>> with a tortured uu-encoded file that would cause uudecode to seg fault.
>
> Would be nice to add a test case for it... Is the uu-encoded file that
> caused the crash available somewhere public? Or would it be easy to
> create a simple test case with the same kind of problem?

It was in an email that got to me somehow:

> $ od -c stackoverflow.uu
> 0000000   b   e   g   i   n   0   ~
> 0000007
> $ uudecode stackoverflow.uu
> uudecode fatal error:
> stackoverflow.uu: Invalid or missing 'begin' line

Reading through the various docs I found lots of weasel words saying
decode is not robust against pathological inputs.  Still, the above
is now fixed:

     http://autogen.sourceforge.net/data/sharutils-4.15.1.4-ed86.tar.xz

but that is not to say you couldn't cook up another.  It's a bit harder now.
There is also a bit more to play with.  POSIX currently defines two "begin" lines:

    begin-base64 <mode> <decoded-path-name>
    begin <mode> <decoded-path-name>

In order to allow arbitrarily international "decoded path name"s, the
current code (as a POSIX extension) added another "-encoded" option
to the begin.  It may appear by itself, or also before or after the "-base64",
yielding 5 variations on "begin":

    begin-encoded <mode> <encoded-decoded-path-name>
    begin-base64-encoded <mode> <encoded-decoded-path-name>
    begin-encoded-base64 <mode> <encoded-decoded-path-name>

with the last two being effectively the same.  The "encoded-decoded-
path-name" is base64 encoded.  So continuing the above example:

> $ f=stackoverflow.uu ; uuencode -m -e $f < $f
> begin-base64-encoded 644 c3RhY2tvdmVyZmxvdy51dQ==
> YmVnaW4wfg==
> ====

the last three lines could be reconstructed into the problematical file.