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
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 b
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
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 libic
> 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 c
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 concl
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 wind
> 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. So
> On Jun 7, 2018, at 11:19 AM, 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. An
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 r
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,
> >
>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.
___
In message on Thu, 7 Jun
2018 17:55:27 +0200, Andy Polyakov said:
appro> > 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,
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
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. Wh
>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.
__
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 RT
"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 plat
> It already isn't. Depending on your regional settings, a passphrase isn't
> always encoded the same way.
So no, not a first.
That is *different.* That is a user setting changing behavior. This would be
the exact same executable, and even user settings, doing different things.
_
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 - o
>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
"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'
>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-projec
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.
> 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 t
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
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
> > > *cur
27 matches
Mail list logo
