> On Jun 12, 2018, at 3:39 PM, Richard Levitte <levi...@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.


openssl-project mailing list

Reply via email to