Re: base64 tool?

[Simon Josefsson]

Eric Blake <address@hidden> writes:

> According to Simon Josefsson on 6/27/2005 3:55 PM:
>> 
>> -w is for encoding, -i for decoding.  So they are orthogonal.  I
>> thought about making -w affect decoding to, so decoding would ignore
>> (only) newlines after COLS.  Could be fixed later on.
>
> I would have suggested this as well; I like the thought of -w during
> encoding adds newline at COL and at EOF, and -w during decoding ignores
> newline only at COL and EOF.

Yes.

> As to your questions on other command line interfaces, I think base64
> should at least behave as a filter:
> base64 < file > file.b64
> base64 -d < file.b64 > file

Yup.  This is possible now.

> As for whether choosing on "base64 abc" whether abc is the filename
> containing text to be encoded, or the actual text to be encoded, I would
> lean towards filenames.

Me too.  The tool started out as a debugging tool for me, but it is
not the typical use.  And 'base64 -s foo' is simple for short tests.
Or should it be 'base64 -e foo'?  To match 'grep -e ...' or 'perl -e
...'.  'foo' is a string here, not a filename.

> Consider that your typical input is arbitrary
> length binary data, and passing that binary data directly as a command
> line argument is not a typical usage of a textual command line interface.
>  Besides, if you can easily type the input as an ASCII argument, why do
> you need the 133% size penalty of encoding it?  For a single file, it
> might make sense to support a -o/--output option to specify the name of
> the output file.  Then "base64" would be equivalent to "base64 - -o -".
> I'm not sure of the best approach for scaling it to multiple input or
> output files, or if that is even necessary.

Dealing with multiple input files could also be done later on, I think
it is more important to make sure the arguments are filenames and not
strings now.

> Does the RFC permit, recommend, or discourage \r\n line endings in base64
> encodings?  Since the output is printable, you may want to consider
> carefully the decision between opening the coded file in text vs. binary
> modes on platforms where they are different.  The decoded file must
> definitely be opened binary.

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.

Cheers,
Simon