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

2018-06-07 Thread Kurt Roeckx
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 > > >

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

2018-06-07 Thread Kurt Roeckx
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, >

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

2018-06-07 Thread Viktor Dukhovni
> 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

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

2018-06-07 Thread Salz, Rich
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

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

2018-06-07 Thread Salz, Rich
>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. ___

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

2018-06-07 Thread Richard Levitte
"Salz, Rich" skrev: (7 juni 2018 21:29:40 CEST) >>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

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

2018-06-07 Thread Salz, Rich
>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

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

2018-06-07 Thread Richard Levitte
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 -

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

2018-06-07 Thread Richard Levitte
"Salz, Rich" skrev: (7 juni 2018 21:09:55 CEST) >>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 > >That then means that the pkcs12 program is not compatible in behavior >across

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

2018-06-07 Thread Viktor Dukhovni
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

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

2018-06-07 Thread Salz, Rich
>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 That then means that the pkcs12 program is not compatible in behavior across platforms. This would be a first, for us.

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

2018-06-07 Thread Richard Levitte
In message on Thu, 7 Jun 2018 16:58:20 +0200, Andy Polyakov said: appro> One can argue that iconv was actually standardized, and in such appro> case it would be appropriate to make it conditional on appro> _POSIX_VERSION. [Though it doesn't seem to be part of pull appro> request in question.

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

2018-06-07 Thread Richard Levitte
In message on Thu, 7 Jun 2018 11:56:00 -0400, Viktor Dukhovni said: openssl-users> openssl-users> openssl-users> > On Jun 7, 2018, at 11:19 AM, Richard Levitte wrote: openssl-users> > openssl-users> > Regarding general use of other libraries, please openssl-users> > think carefully before

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

2018-06-07 Thread Salz, Rich
>Taking off on a bit of a tangent, how much justification did we go through when adding pthreads as a dependency. It's an optional, but enabled by default, dependency which is different. We had a lot of discussion within what was then openssl-team.

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

2018-06-07 Thread Benjamin Kaduk
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, >

Re: [openssl-project] Votes on the use of other libraries in general and iconv in particular

2018-06-07 Thread Kurt Roeckx
On Thu, Jun 07, 2018 at 05:09:52PM +0200, Richard Levitte wrote: > Mm, I was thinking about it, but then, we have already discussed this in > circles on github. I do not follow everything on github, I had no idea that this was being discussed. Someone might have convinced you that it's not the

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

2018-06-07 Thread Andy Polyakov
> 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.

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

2018-06-07 Thread Richard Levitte
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

Re: [openssl-project] Votes on the use of other libraries in general and iconv in particular

2018-06-07 Thread Richard Levitte
Mm, I was thinking about it, but then, we have already discussed this in circles on github. Besides, those are two week votes, and I now realised I did a procedural error when settling a closed date (what the hell was I thinking?). But still, that gives two weeks before the vote has to be

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

2018-06-07 Thread Andy Polyakov
> 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

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

2018-06-07 Thread Salz, Rich
I see you already started the votes. No time for discussion? I think OpenSSL should be a "fundamental" system library. Perhaps the apps are different, but it should not require new libraries but could use them if available -- either at run-time or via config/build. I think iconv in

[openssl-project] Votes on the use of other libraries in general and iconv in particular

2018-06-07 Thread Richard Levitte
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

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

2018-06-07 Thread Richard Levitte
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