[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: base64 tool?
Re: base64 tool?
Tue, 28 Jun 2005 14:47:01 +0000
> 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.
Re: base64 tool?,
Eric Blake <=
- Re: base64 tool?, (continued)
- Re: base64 tool?, Jim Meyering, 2005/06/25
- Re: base64 tool?, Simon Josefsson, 2005/06/25
- Re: base64 tool?, Paul Eggert, 2005/06/26
- Re: base64 tool?, Simon Josefsson, 2005/06/27
- Re: base64 tool?, Eric Blake, 2005/06/28
- Re: base64 tool?, Simon Josefsson, 2005/06/28
- Re: base64 tool?, Brian Dessent, 2005/06/28