bug-coreutils
[Top][All Lists]
Advanced

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

Re: [Bug 204567] New: base64 -d doesn't accept base64 output


From: Simon Josefsson
Subject: Re: [Bug 204567] New: base64 -d doesn't accept base64 output
Date: Mon, 18 Sep 2006 12:46:25 +0200
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux)

I agree that this is a bug, and I'm interested in fixing this, but I
have little free time right now.

I'd prefer that --wrap can be used to indicate at what position the
tool should expect CR/LF on decoding.  If there isn't a CR/LF at that
position, it should abort.

Also, there should be one new parameter to make the tool accept one
additional CR/LF after the data when decoding, and it should probably
default to on, or possibly only default to on when --wrap is used.

If anyone wants to take a stab at implementing this, that would be
great...  I'll get to it eventually, otherwise.

/Simon

Jim Meyering <address@hidden> writes:

> In https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=204567,
>
> James Antill wrote:
>> Summary: base64 -d doesn't accept base64 output
>>
>> Description of problem:
>>  base64 -d doesn't accept returns (which the base64 encoding should put
>>  every 76 characters and at the end of the encoding).
>>
>> Version-Release number of selected component (if applicable):
>>  coreutils-5.97-6
>>
>> How reproducible:
>>  Always
>>
>> Steps to Reproduce:
>> 1. echo x | base64 | base64 -d
>> 2. perl -le 'print "a" x 80' | base64 | base64 -d
>>
>> Additional info:
>>  base64 -id does work but (IMNSHO) the output of base64 and what the rfc says
>> you should do should hardly be clasified as garbage. However this does 
>> present
>> the obvious fix of looking for '\n' (and skipping it) on the else clause of 
>> the
>> ignore_garbage check.
>
> Thanks for the report and the patch.
>
> I suspect you know it already, but for the record,
> an alternative is to filter out newlines before running base64 -d
> or to encode with --wrap=0, to avoid emitting newlines altogether.
> But your point is valid.
>
>> ------- Additional Comments From address@hidden
>> Created an attachment (id=135184)
>> --> 
>> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=135184&action=view)
>> Simple fix for base64 decoding return's
>>
>>  This is a simple fix, although not very efficient and allows some things
>> through that shouldn't be allowed without -i. On the other hand it's so 
>> simple
>> it's obviously OK to apply.
>
> I agree that implying base64-added newlines are "garbage" is not
> aesthetically pleasing :)  I'd prefer a change that adds an option to
> ignore newlines (or maybe an arbitrary set of bytes) efficiently.
> Of course, that would require more invasive changes.
>
> Simon Josefsson (Cc'd) wrote both the program and much of the base64
> gnulib module, so maybe he'll be interested in looking at this.




reply via email to

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