[openssl-project] To use or not use the iconv API, and to use or not use other libraries

Viktor Dukhovni openssl-users at dukhovni.org
Tue Jun 12 20:02:16 UTC 2018



> On Jun 12, 2018, at 3:39 PM, Richard Levitte <levitte at openssl.org> wrote:
> 
>> The flags I'd like to see are:
>> 
>>   -latin1:  Passphrase is a stream of octets, each of which is a single unicode
>>             character in the range 0-255.
> 
> I would prefer to call it -binary or something like that...  it
> certainly comes down to the same thing in practice, and should
> translate exactly to the pre-1.1.0 behaviour.

I won't quibble over the name.

> 
>>   -utf8:    Passphrase is already utf-8 encoded
>> 
>>   -ascii:   Passphrase must be ASCII, reject inadvertent 8-bit input.
> 
> ... and if none of these are given?

Not sure.  We could opt for "-binary" by default, which is backwards
compatible, but it produces non-standard outputs, which is a disfavour
to new users.  We could go with "-ascii" as a default, forcing failure
for non-ascii passwords without an explicit indication of encoding.
The second seems more appealing to me.

>> And as available:
>> 
>>   -toutf8:   Convert passphrase from the input encoding to UTF-8.
>> 	     Either using the locale-specific encoding, or yet
>>              another flag:
>> 
>>   -encoding: A platform-specific name for the input encoding understood
>>              by the system's encoding conversion library (iconv on Unix).
> 
> If the availability of -toutf8 depends on the presumed presence of
> iconv(), then we can assume that nl_langinfo() is present as well.
> That renders -encoding unnecessary, unless you want to use it to
> override the locale-specific encoding.

The purpose is specifically to override the encoding when it is wrong
for some reason.  The iconv library takes the empty string as the
locale-specific encoding, so we should not need nl_langinfo(), unless
that's known to produce better results.

-- 
	Viktor.



More information about the openssl-project mailing list