Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries
> On Jun 12, 2018, at 6:56 PM, Richard Levitte wrote: > > Some implementations of the iconv library take the empty string as > the locale-specific encoding, but that is in no way universal, and > isn't specified in the standard: > > http://pubs.opengroup.org/onlinepubs/009695399/functions/iconv_open.html > > Using nl_langinfo() to get the locale-specific encoding will, as far > as I know, always get you what you expect. On FreeBSD, after (required) calling: setlocale(LC_CTYPE, ""); The nl_langinfo(CODESET) returns the correct charset for by UTF-8 terminal emulator for which my environment has: LC_CTYPE=en_US.UTF-8 With that, iconv_open() and iconv() behave correctly converting to from ISO-8859-1 and UTF-8 (minimal tests). Without the setlocale() call, my encoding is always US-ASCII, and iconv is naturally crippled. -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries
In message <333784c8-4870-4ddb-a892-13d552724...@dukhovni.org> on Tue, 12 Jun 2018 16:02:16 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 12, 2018, at 3:39 PM, Richard Levitte wrote: openssl-users> > openssl-users> >> The flags I'd like to see are: openssl-users> >> openssl-users> >> -latin1: Passphrase is a stream of octets, each of which is a single unicode openssl-users> >> character in the range 0-255. openssl-users> > openssl-users> > I would prefer to call it -binary or something like that... it openssl-users> > certainly comes down to the same thing in practice, and should openssl-users> > translate exactly to the pre-1.1.0 behaviour. openssl-users> openssl-users> I won't quibble over the name. openssl-users> openssl-users> > openssl-users> >> -utf8:Passphrase is already utf-8 encoded openssl-users> >> openssl-users> >> -ascii: Passphrase must be ASCII, reject inadvertent 8-bit input. openssl-users> > openssl-users> > ... and if none of these are given? openssl-users> openssl-users> Not sure. We could opt for "-binary" by default, which is backwards openssl-users> compatible, but it produces non-standard outputs, which is a disfavour openssl-users> to new users. We could go with "-ascii" as a default, forcing failure openssl-users> for non-ascii passwords without an explicit indication of encoding. openssl-users> The second seems more appealing to me. Same here. openssl-users> >> And as available: openssl-users> >> openssl-users> >> -toutf8: Convert passphrase from the input encoding to UTF-8. openssl-users> >>Either using the locale-specific encoding, or yet openssl-users> >> another flag: openssl-users> >> openssl-users> >> -encoding: A platform-specific name for the input encoding understood openssl-users> >> by the system's encoding conversion library (iconv on Unix). openssl-users> > openssl-users> > If the availability of -toutf8 depends on the presumed presence of openssl-users> > iconv(), then we can assume that nl_langinfo() is present as well. openssl-users> > That renders -encoding unnecessary, unless you want to use it to openssl-users> > override the locale-specific encoding. openssl-users> openssl-users> The purpose is specifically to override the encoding when it is wrong openssl-users> for some reason. The iconv library takes the empty string as the openssl-users> locale-specific encoding, so we should not need nl_langinfo(), unless openssl-users> that's known to produce better results. Some implementations of the iconv library take the empty string as the locale-specific encoding, but that is in no way universal, and isn't specified in the standard: http://pubs.opengroup.org/onlinepubs/009695399/functions/iconv_open.html Using nl_langinfo() to get the locale-specific encoding will, as far as I know, always get you what you expect. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries
> On Jun 12, 2018, at 3:39 PM, Richard Levitte 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. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries
In message on Tue, 12 Jun 2018 11:06:40 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 7, 2018, at 3:40 PM, Salz, Rich wrote: openssl-users> > openssl-users> > I think you forgot that this is not what I suggested. One flag indicates it's utf-8 encoded, don't touch it. The other flag indicates it might have high-bit chars, don't touch it. openssl-users> openssl-users> The flags I'd like to see are: openssl-users> openssl-users> -latin1: Passphrase is a stream of octets, each of which is a single unicode openssl-users> 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. openssl-users> -utf8:Passphrase is already utf-8 encoded openssl-users> openssl-users> -ascii: Passphrase must be ASCII, reject inadvertent 8-bit input. ... and if none of these are given? openssl-users> And as available: openssl-users> openssl-users> -toutf8: Convert passphrase from the input encoding to UTF-8. openssl-users> Either using the locale-specific encoding, or yet openssl-users> another flag: openssl-users> openssl-users> -encoding: A platform-specific name for the input encoding understood openssl-users> 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. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries
> On Jun 7, 2018, at 3:40 PM, Salz, Rich wrote: > > I think you forgot that this is not what I suggested. One flag indicates > it's utf-8 encoded, don't touch it. The other flag indicates it might have > high-bit chars, don't touch it. 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. -utf8:Passphrase is already utf-8 encoded -ascii: Passphrase must be ASCII, reject inadvertent 8-bit input. 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). None of these flags change semantics after introduction. -- -- Viktor. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Please approve 6457 for backport
This is the PR for the CVE. I forgot to add the branches to the PR...this is for 1.1.0 and 1.0.2. Please can someone approve the backport asap? Thanks Matt ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries
In message <2418fe0a-8a61-47ad-9e60-f40bd0c79...@openssl.org> on Mon, 11 Jun 2018 19:29:09 +0200, Richard Levitte said: levitte> levitte> levitte> "Salz, Rich" skrev: (11 juni 2018 18:54:37 CEST) levitte> >>Except that, because of the way PKCS12_gen_mac() works, this isn't levitte> >true. If the input pass phrase looks like a UTF-8 encoded string levitte> > (because there are valid characters in other encodings that will like levitte> > like UTF-8 byte sequences), it will be used as if -passutf8 was given levitte> >instead. levitte> > levitte> >Well, at least I started down the path. I wonder if one of those flags levitte> >should set the keygen to asc? levitte> levitte> That could be an idea, except that's not an easy change. Effectively, that's exactly equivalent to doing a naïve utf-8 encode in the application. BTW, this subthread is a development discussion... shouldn't that be happening on github, along with a WIP PR? -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
