[Top][All Lists]
[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.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: [Bug 204567] New: base64 -d doesn't accept base64 output,
Simon Josefsson <=