Re: [openssl-project] To use or not use the iconv API, and to use or not use other libraries
On Thu, Jun 07, 2018 at 12:07:34PM -0500, Benjamin Kaduk wrote: > On Thu, Jun 07, 2018 at 05:55:27PM +0200, Andy Polyakov wrote: > > > Regarding general use of other libraries, please think carefully before > > > voting, 'cause this *is* tricky. If you have a look, you will see that we > > > *currently* depend on certain standard libraries, such as, for example, > > > libdl. > > > > One has to recognize that each dependency has to be justified. Sometimes > > you don't have a choice. For example if you want to talk network on > > Solaris, you have to link with -lsocket -lnsl. It's just part of the > > game. But in cases one has a choice, well, one has a choice to *make*. > > And key question is how do you anchor it. It's only natural to have as > > little dependencies as possible, so question is what would justify extra > > dependency. > > Taking off on a bit of a tangent, how much justification did we go > through when adding pthreads as a dependency. I have not been > following very much (Kurt would know more), but apparently in Debian > there are some issues regarding (statically linked?) applications > and libraries that use libcrypto but do not explicitly link with > -pthread. "Issues" here being, IIRC, crashes at runtime. I haven't really followed it, I just saw some mentionng of it on IRC. At least static linkig glibc itself is complicated. I guess it's also complicated because libc itself contains stubs for the pthread functions, so at least the order of the libraries will be important when linking staticly. But I didn't read anything about crashes, I might have missed things. Kurt ___ 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 Thu, Jun 07, 2018 at 05:19:48PM +0200, Richard Levitte wrote: > Regarding general use of other libraries, please think carefully before > voting, 'cause this *is* tricky. If you have a look, you will see that we > *currently* depend on certain standard libraries, such as, for example, > libdl. And perhaps we should also mention the pile of libraries used with > windows. We also started depending on pthread in 1.1.0 ... Kurt ___ 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:59 PM, Salz, Rich wrote: > > If B<-pass8bit> is given, the password is taken to be encoded in the current > locale, but is still used directly. > A future release might automatically convert the password to valid UTF-8 > encoding if this flag is given. I would propose that "-pass8bit" means that each byte of the input is a unicode code point value (i.e. ASCII or LATIN1 supplement) and we'll convert to UCS-2 by prepending 0x00 to each one. If so, I would expect this flag to NOT ever change its meaning. We may internally convert to UTF-8 and then to UTF-16 largely undoing the first conversion, but that just internal API gymnastics, not user- observable. -- 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
Here is proposed documentation for what I am suggesting. =item B<-passutf8>, B<-pass8bit> These flags indicate the character set encoding on the password value. By default, non-ASCII characters are rejected. This is new to OpenSSL 1.1.1, and is used to enforce complains with the PKCS#12 standard. If B<-passutf8> is given, then the password is taken to be valid UTF-8 encoding, and will be used directly. If B<-pass8bit> is given, the password is taken to be encoded in the current locale, but is still used directly. A future release might automatically convert the password to valid UTF-8 encoding if this flag is given. On 6/7/18, 3:42 PM, "Salz, Rich" wrote: >So even rejecting correctly encoded utf-8? 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-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project ___ 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
>My main concern is that currently, openssl pkcs12 may create broken pkcs12 > files (because it misinterprets the pass phrase when constructing a > BMPString), and doesn't notify the user at all (doesn't even check). For those who haven't reada the PR and all its comments, I propose that we reject non-ASCII input unless one of two flags is set. This prevents us from unknowingly making the situation worse, and does not break interop with our installed base. ___ 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
Viktor Dukhovni skrev: (7 juni 2018 21:16:53 CEST) >On Thu, Jun 07, 2018 at 09:01:15PM +0200, Richard Levitte wrote: > >> We don't have to answer the question "how high" now. I'm fully >> prepared to have the use of iconv limited to platforms where we know >> it's available (for example, we - or well, *I* - know that VMS has >the >> iconv API in the C RTL, not even any need to link with any extra >> library... and we *know* it's available in glibc since version >> 2.something). I'm fully prepared to have to deal with people saying >> "hey, we have that too!" and having to edit config targets as we go. >> I do not expect any support of iconv to cover more than what we can >> test or get patches for, as with anything else. > >There's also apparently some variation in the iconv API function >prototypes (possibly "const char **" vs. "char **"). So some >platform-dependent casting may be required... > >My peers suggest that this late in the release cycle, we leave the >responsibility of ensuring UTF-8 input to the user. We could >describe work-arounds in documentation. Personally, if this is >off by default, and requires a new option to enable, and is just >in openssl(1) and not libcrypto, I'm disinclined to say "no" until >I see a PR (with documentation) that we can decide to leave for >post 1.1.1 or adopt. Please review doc/man7/passphrase-encoding.pod My main concern is that currently, openssl pkcs12 may create broken pkcs12 files (because it misinterprets the pass phrase when constructing a BMPString), and doesn't notify the user at all (doesn't even check). Cheers Richard -- Skickat från min Android-enhet med K-9 Mail. Ursäkta min fåordighet. ___ 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
Regarding general use of other libraries, please think carefully before voting, 'cause this *is* tricky. If you have a look, you will see that we *currently* depend on certain standard libraries, such as, for example, libdl. And perhaps we should also mention the pile of libraries used with windows. In my mind, this makes that more general vote ridiculous, but the matter was brought up to me, and I wasn't going to ignore it, no matter what my personal feelings are. Cheers Richard Richard Levitte skrev: (7 juni 2018 13:54:11 CEST) >Hi, > >This PR has been blocked, forcing a vote: > >https://github.com/openssl/openssl/pull/6392 > >Background: we have been sloppy when producing PKCS#12 files, creating >objects that aren't interoperable. This can only happen with non-UTF8 >input methods, so this PR adds a higher level of control in the >openssl application, so that it will do the best it can to make sure a >pass phrase encoded with something other than UTF-8 gets correctly >re-encoded, and failing that, try and make the user aware that they >are about to create a non-interoperable object. This triggered the >use of the iconv API, and in the case of Mac OS/X, the use of the >separate libiconv library. > >I'm going to make this into two votes, as both topics have come out >because of this. > >1. A vote about general use of other libraries, limited to standard > system libraries, which may be platform dependent (I expect > libiconv on Mac OS/X to be such a library) > >2. A vote about the use of the iconv API > >Please discuss here, no in the vote threads. > >Cheers, >Richard -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openssl-project mailing list openssl-project@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-project
[openssl-project] Votes on the use of other libraries in general and iconv in particular
Hi, as promised, I've create two votes: -- topic: We can use other standard / system libraries, per config target A current example is using libiconv on Mac OS/X. We will be cautious in doing so in the libraries, and are more free to do so in applications. Proposed by Richard Levitte Public: yes opened: 2018-06-07 closed: 2018-06-21 -- topic: We can use the iconv API in our applications Proposed by Richard Levitte Public: yes opened: 2018-06-07 closed: 2018-06-21 -- The vote tallies will be presented here when the votes are closed. 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
[openssl-project] To use or not use the iconv API, and to use or not use other libraries
Hi, This PR has been blocked, forcing a vote: https://github.com/openssl/openssl/pull/6392 Background: we have been sloppy when producing PKCS#12 files, creating objects that aren't interoperable. This can only happen with non-UTF8 input methods, so this PR adds a higher level of control in the openssl application, so that it will do the best it can to make sure a pass phrase encoded with something other than UTF-8 gets correctly re-encoded, and failing that, try and make the user aware that they are about to create a non-interoperable object. This triggered the use of the iconv API, and in the case of Mac OS/X, the use of the separate libiconv library. I'm going to make this into two votes, as both topics have come out because of this. 1. A vote about general use of other libraries, limited to standard system libraries, which may be platform dependent (I expect libiconv on Mac OS/X to be such a library) 2. A vote about the use of the iconv API Please discuss here, no in the vote threads. 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
