[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