Re: base64 tool?

[Simon Josefsson]

address@hidden (Eric Blake) writes:

>> The RFC is fuzzy on the issue, but I want to discourage too lax
>> treatment of encoded data.  Lax treatment create opportunities for
>> side channel attacks, and make implementations complex since they have
>> to deal with various ill-formed input.  So without --wrap, I
>> definitely think the file should be opened as binary.  But with wrap
>> it is less clear.  The RFC doesn't discuss what "newline" means.  So I
>> think we should open it as text.  More thoughts appreciated.
>
> One thing to remember is that many RFCs expect \r\n (consider SMTP,
> HTTP, etc), so it might be nice to allow that even on Unix systems where
> only \n is normal!  Maybe it is worth a command-line argument, where
> on encoding you can change the default line-ending (this requires opening
> in binary mode to guarantee that the OS doesn't change your wishes),
> and on decoding you can choose whether to be lax on any line-ending
> or robust to only allow one type of line-ending (again, this implies binary
> mode).  But it's your call (esp. since you are the editor of RFC 3548 :).
>
> How about -l/--line-ending ENDING where ending is 'crlf', 'cr', 'lf', or 
> 'any',
> and omitting -l or using -lany on encode defaults to lf, and omitting -l on
> decode defaults to any.

I wish I could avoid falling into the EOL-sandpit, it appear complex
and error prone...  I'll try to get the tool up and running according
to the other comments first, and then revisit this issue when things
are more clear code-wise.  Don't let that stop you from thinking about
this, there may be other ideas worth investigating.

Thanks,
Simon