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
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
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
> 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
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
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
> 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.
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 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.
>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.
"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
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
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
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
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 -
>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
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
> > >
>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.
___
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
> 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
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,
>
23 matches
Mail list logo
