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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] >> 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. _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
