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 
> > > *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

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, 
> 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

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 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

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 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

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.


___
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

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 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.

So even rejecting correctly encoded utf-8?

-- 
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

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 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

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 - 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

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 platforms.  This would be a first, for us.

It already isn't. Depending on your regional settings, a passphrase isn't 
always encoded the same way. 
So no, not a first. 

-- 
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

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 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.

-- 
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

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.


___
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

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. Why not?] But as far as _POSIX_VERSION
appro> goes, we kind of know that some systems by *default* offer
appro> lower version, presumably in order to facilitate backward
appro> portability.

[about why not: because I was unsure how _POSIX_SOURCE is defined...
having seen too many places where the user (i.e. us) gets to define
that macro to get desired features.  I've read up since, so expect a
change that uses this macro]

appro> So that it would mean that we would have to explicitly rise the
appro> bar in some cases. Which ones? And how high? This brings us to
appro> following question. Is *this* actually right moment to
appro> introduce that kind of *multi-variable* problem? In other words
appro> the problem kind of has two sides: a) principal, to do or not
appro> to do; b) *when* would it be appropriate to start, is minor
appro> release right moment? Is b) part of the vote?

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.

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

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 voting, 'cause this *is*
openssl-users> > tricky. If you have a look, you will see that we
openssl-users> > *currently* depend on certain standard libraries,
openssl-users> > such as, for example, libdl. And perhaps we should
openssl-users> > also mention the pile of libraries used with
openssl-users> > windows.
openssl-users> > 
openssl-users> > In my mind, this makes that more general vote
openssl-users> > ridiculous, but the matter was brought up to me, and
openssl-users> > I wasn't going to ignore it, no matter what my
openssl-users> > personal feelings are.
openssl-users> 
openssl-users> My concern is not so much whether a dependency on libiconv in 
libcrypto
openssl-users> should be allowed, but rather wether we actually need it.  I 
rather
openssl-users> think that all codepage conversions should be the application's 
job.
openssl-users> 
openssl-users> Thus, it is OK for *apps* where we prompt for passwords to 
support
openssl-users> conversion to UTF-8, perhaps via libiconv.  So I see 
/usr/bin/openssl
openssl-users> linked against the iconv API (which is, for example, in libc on 
NetBSD
openssl-users> and FreeBSD, and does not require a separate library).  We 
probably
openssl-users> require libiconv for "openssl pkcs12" to work correctly, but the
openssl-users> dependency should IMHO be in apps not libcrypto.

Yup, and I did hear you in that other thread.  Your argument about
having OSSL_STORE be at liberty to *expect* UTF-8 without having to
check for it made sense to me, and I did move the check and possible
conversion to the application (i.e. 'openssl pkcs12').  That's what
the PR I pointed at is all about.

-- 
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

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.

___
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

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, 
> > 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.

-Ben
___
openssl-project mailing list
openssl-project@openssl.org
https://mta.openssl.org/mailman/listinfo/openssl-project


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 right vote, or
that the wording could be improved.


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

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. 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.

> And perhaps we should also mention the pile of libraries used with windows.

It's not about amount, but ubiquity and stability. Windows is bad
example in the context, because it's rather "mono-cultural" environment.
But *otherwise* thing is that we already *know* that those extra
libraries work. Or at least know what to expect and how to deal with
them on different platforms. They were effectively proven to work by
lasting through several releases and years-long bug ironing. This *is*
factor too. And that's what made me pose "is b) part of vote" in my last
post.
___
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

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 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


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 concluded, does that not allow 
discussion? Has that ever stopped us from discussing before? 

Cheers
Richard 

"Salz, Rich"  skrev: (7 juni 2018 16:51:30 CEST)
>I am disappointed that no time was allowed for discussion.
>
>On 6/7/18, 8:38 AM, "Richard Levitte"  wrote:
>
>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 mailing list
>openssl-project@openssl.org
>https://mta.openssl.org/mailman/listinfo/openssl-project

-- 
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

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 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 find the reference to Mac OS X a bit misleading, because it suggests
that assessment was made on limited amount of data points. Basically on
how does it look on *contemporary* Linux/Unix platforms and Mac OS X.
But question runs deeper than that and should cover all platform that we
consider supporting. Which covers even ranges of older versions, in
sense that judging on latest version alone is hardly sufficient. For
example do we know *when* was libiconv introduced to Mac OS X? One can
naturally say that we are not obliged to care about *that* old versions,
but this is no excuse for not making thorougher assessment? I mean it's
only appropriate if we can answer the question how old does system have
to be for us to say "we don't care". And same question applies even to
other platforms, OpenBSD, FreeBSD, Android, Cygwin, Solaris, AIX, HP-UX,
DJGPP, Tru64, IRIX, ... One can argue that iconv was actually
standardized, and in such case it would be appropriate to make it
conditional on _POSIX_VERSION. [Though it doesn't seem to be part of
pull request in question. Why not?] But as far as _POSIX_VERSION goes,
we kind of know that some systems by *default* offer lower version,
presumably in order to facilitate backward portability. So that it would
mean that we would have to explicitly rise the bar in some cases. Which
ones? And how high? This brings us to following question. Is *this*
actually right moment to introduce that kind of *multi-variable*
problem? In other words the problem kind of has two sides: a) principal,
to do or not to do; b) *when* would it be appropriate to start, is minor
release right moment? Is b) part of the vote?
___
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

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 particular is a bad thing to require at this time, in a 1.1.1 
release.  It's not clear to me that it meets our API/ABI compatibility 
guarantee.  I also dislike iconv because of its size, the fact that it is a 
gross collection of hacks -- not its fault, it's the nature of charsets -- and 
that it is not universal.  This means that apps that "do the right thing" on 
some platforms, will FAIL to do so on opthers.

It is very very late in the release process to be adding a new dependency.

Finally, I believe that for this particular issue, we can add an API that 
enables applications to do the right thing, and we can add flags and warnings 
to the command-line that make it more clear when a user isn't doing the right 
thing (such as because they have existing files they need to read).

VOTE NO.

On 6/7/18, 8:04 AM, "Richard Levitte"  wrote:

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


___
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

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 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

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 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