[openssl-dev] [openssl.org #4149] [PATCH] ssl_set_pkey() unnecessarily updates certificates

Hello OpenSSL.org We have found the following issue in 1.0.2 and master branches of OpenSSL: ssl_set_pkey() unnecessarily updates certificates Some key types types (EC, DSA, DH, but not RSA) have separate parameters that are needed for correct operation. When ssl_set_pkey() is called (via

Re: [openssl-dev] We're working on license changes

--On Friday, November 20, 2015 9:28 PM + Jonathan Larmour wrote: So a dual license still seems desirable to me. However, also, and as I said when this came up before, I don't believe the OpenSSL team is legally permitted to change the license as they do not hold the entire copyright. To cha

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

Quite reasonable except. I'm not sure you have majority and minority the right way around. My guess would be that the majority of OpenSSL users are libcrypto. consumers rather than SSL/TLS consumers. A point several of us have been trying to get through for some time. Peter-"openssl-dev"

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

While I am all for simplicity, I also think that removing functionality is a “bad idea”. To reduce the support burden, deprecate the ciphers: 1. Under support, indicate that these ciphers will no longer receive fixes. 2. Remove any assembly implementations 3. Disable them by default. I suggest f

Re: [openssl-dev] We're working on license changes

> you need a copyright assignment or Contributor License Agreement from every > individual or company who has contributed code to OpenSSL. You cannot change > the terms of something you do not own. That is admittedly a significant > hurdle to any change. Yup. That's why it will take a while. _

Re: [openssl-dev] [openssl.org #4100] Overlapping memcpy arguments in bn_add.c

> 4/ in BN_usub, ap = a->d; and rp = r->d; > then the 2 pointers can be incremented, but an identical number of times > > 5/ then memcpy is called with rp and ap that are still aliases, which is > undefined behavior The patch has been applied. Kurt _

Re: [openssl-dev] We're working on license changes

On 20/11/15 20:48, Salz, Rich wrote: >> Is there a possibility of releasing it under more than one license? > > Highly doubtful, at least not at first. > >> Otherwise, I honestly don't really see the point of relicensing >> OpenSSL as moving to apache v2 does not resolve the primary problem >> wi

Re: [openssl-dev] We're working on license changes

--On Friday, November 20, 2015 9:47 PM +0100 Richard Levitte wrote: I would like to point out that the GNU project talks about the Apache v2 license in positive terms: http://www.gnu.org/licenses/license-list.html When dealing with the GPLv3, yes. However, it clearly notes the incompatibi

Re: [openssl-dev] We're working on license changes

>Is there a possibility of releasing it under more than one license? Highly doubtful, at least not at first. > Otherwise, I honestly don't really see the point of relicensing OpenSSL as > moving to apache v2 does not resolve the primary problem with the OpenSSL > license that currently exists.

Re: [openssl-dev] We're working on license changes

In message <313961D7FE900DC0D4BE4654@[192.168.1.9]> on Fri, 20 Nov 2015 12:37:13 -0800, Quanah Gibson-Mount said: quanah> --On Friday, November 20, 2015 7:34 PM + "Salz, Rich" quanah> -- wrote: quanah> quanah> > It's almost definitely going to be Apache v2. quanah> quanah> Is there a possi

Re: [openssl-dev] We're working on license changes

--On Friday, November 20, 2015 7:34 PM + "Salz, Rich" wrote: It's almost definitely going to be Apache v2. Is there a possibility of releasing it under more than one license? Otherwise, I honestly don't really see the point of relicensing OpenSSL as moving to apache v2 does not resolve

Re: [openssl-dev] [openssl-users] Removing obsolete crypto from OpenSSL 1.1 - seeking feedback

On 11/19/2015 12:28 PM, Viktor Dukhovni wrote: > What algorithms people use on > their own data is their choice and risk decision not ours. I heartily agree with the sentiment. A low- or mid-level library is not the right place to be making and enshrining policy decisions. We can take yet anoth

Re: [openssl-dev] PBE_UNICODE

> There is a specification in > Russian, > http://tk26.ru/methods/containers_v1/Addition_to_PKCS8&PKCS12_v1_0.pdf > > It says: > "The password Psw should be represented in UTF-8 format without trailing > zero byte and passed as the P element of the PBKDF2 algorithm" Yeah, but this describes spec

Re: [openssl-dev] We're working on license changes

It's almost definitely going to be Apache v2. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

Re: [openssl-dev] PBE_UNICODE

>> The way I read PKCS12 the string should be big-endian UTF-16 one. > [...] >> Correct procedure should be to convert it to wchar_t and >> then ensure correct endianness. > > Please note that wchar_t itself might not have any relation with > UTF. You should explictly convert from the locale char

Re: [openssl-dev] We're working on license changes

--On Tuesday, August 04, 2015 3:35 PM -0700 Quanah Gibson-Mount wrote: Just curious -- Any update on this? Is OpenSSL going to use something GPLv2 compatible? etc. Thanks, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open sour

Re: [openssl-dev] PBE_UNICODE

On Thu, Nov 19, 2015 at 11:16:23PM +0100, Andy Polyakov wrote: > > The way I read PKCS12 the string should be big-endian UTF-16 one. [...] > Correct procedure should be to convert it to wchar_t and > then ensure correct endianness. Please note that wchar_t itself might not have any relation with

Re: [openssl-dev] PBE_UNICODE

Dear Andy, On Fri, Nov 20, 2015 at 4:51 PM, Andy Polyakov wrote: > > >> ??? So suggestion is leave it as it is? Well, given the presented > >> evidence doing the right thing should break things for you. But does it > >> mean that one can/should be excused from getting things right? > > > > htt

[openssl-dev] [openssl.org #2145] [PATCH] New parameter "signing_digest" for TS module

On Thu Jul 03 00:37:19 2014, jaroslav.imr...@disig.sk wrote: > Thank you for the comment - I have moved the new field at the end of > the TS_RESP_CTX structure. > I have also introduced TS_SIGNING_DIGEST flag that should prevent > binary compatibility issues when application allocates TS_RESP_CTX >

[openssl-dev] [openssl.org #4147] TSA: SHA-1 update

On Wed Nov 18 15:24:50 2015, mxl...@gmail.com wrote: > OpenSSL TSA (ts) code is still using SHA-1 message digest algorithm, > in even two ways: > > * as default message digest algo in the time-stamp query (by default) > * in the time-stamp reply/token signature (hard-coded) > > This pull request at

Re: [openssl-dev] PBE_UNICODE

>> > I do not know whether the authors of the CSP have implemented their own >> > mechanism of transforming the password or used any provided by the >> > Windows system default. >> >> What are chances that they too used same formally incorrect approach? > > I think that they use the system method,

Re: [openssl-dev] PBE_UNICODE

Dear Andy, On Fri, Nov 20, 2015 at 1:48 PM, Andy Polyakov wrote: > > > I understand that there should be problems with Windows. > > To eliminate possibility of misunderstanding. Claim is not limited to > problems with Windows, but that OpenSSL handles non-ASCII characters in > apparently non-inte

Re: [openssl-dev] PBE_UNICODE

On 11/20/15 10:20, Dmitry Belyavsky wrote: > Dear Andy, > > On Fri, Nov 20, 2015 at 12:08 PM, Andy Polyakov > wrote: > > > ... And on Windows it's even worse. As it stands now > > even passing non-ASCII strings as command-line argument [and presumably > > at

Re: [openssl-dev] PBE_UNICODE

Dear Andy, On Fri, Nov 20, 2015 at 12:08 PM, Andy Polyakov wrote: > > ... And on Windows it's even worse. As it stands now > > even passing non-ASCII strings as command-line argument [and presumably > > at prompt] is not an option. > > This is not entirely true. Whether or not one can pass non-A

Re: [openssl-dev] PBE_UNICODE

> ... And on Windows it's even worse. As it stands now > even passing non-ASCII strings as command-line argument [and presumably > at prompt] is not an option. This is not entirely true. Whether or not one can pass non-ASCII strings as command-line argument is language-specific. Or rather code pag