> From: [email protected] On Behalf Of P Fudd via RT
> Sent: Thursday, 03 February, 2011 10:42

> I'm testing smtp auth login using the command line.  One step is to
> encode the username and password with "/bin/echo -ne myusername |
> openssl enc -base64". The opposite step would be "/bin/echo -ne
> bXl1c2VybmFtZQ== | openssl enc -d -base64", but this fails, until the
> -ne is removed.
> 
PEM-standard base64 requires a terminating linebreak, plus 
intermediate linebreaks if the encoding is longer than a 
'normal' line length (about 70 or so, has varied over time), 
so that's what openssl does by default. The standards allow 
additional whitespace, as needed for RFC[2]822-folded headers, 
and AFAICS openssl accepts but doesn't generate that.
Note whitespace isn't in the 64+1-character set, so added 
or changed whitespace doesn't alter the encoded data;
this was deliberate and necessary for its original purpose.

b64BIO, and commandline enc -base64/-a, 
adds newline(s) on encode (at 64 to be on the safe side)
or expects and removes newline(s) on decode.
As you note, if there is no newline on decode, 
it silently returns no data, which can be confusing; 
also if the/an input line is too long (>80 I believe).

In a program you can call BIO_set_flags(,_BASE64_NO_NL) 
and on commandline enc specify -A (uppercase). Latter is 
documented on the man page but not in the usage message.
Then you get continuous data output (possibly inconveniently 
long) or it accepts continuous data input (no newlines).

> Version-Release number of selected component (if applicable):
> openssl-1.0.0c-1.fc14.i686.rpm  (Fedora 14 openssl package)
> 
This particular point hasn't changed in yonks, but thanks 
for specifying because sometimes it does matter.

> Side note: the built-in echo in tcsh doesn't recognize the '-ne', and
> sends it to stdout.  That caused some frustration until I tried
> decoding it and the base64 spelled out "-ne myusername".  For testing,
> use /bin/echo or bash's echo, not tcsh echo.
> 
/bin/echo *on Linux*; on other Unices maybe not. There have been 
several different echo *programs* in history, as well as the also 
different builtins of various shells. Some have used -n, some have 
used \c in the data instead, and the GNU version does both.

Or pipe through tr -d '\n', or use perl (overkill but works):
  perl -e 'print "foo".$/' # newline 
  perl -e 'print "foo\n"' # also (but in more complicated cases
                          # have to worry about re-escaping)
  perl -e 'print "foo"' # not 
(You can enable identifiers and have something like $EOL instead 
of $/, but I don't bother and don't even remember the details. 
And you can use \012 or \12 instead of \n to be el33t.)



______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to