Hi,
I'm one of the people that received the email asking for permission to
relicense code to the new license, Apache 2.0. A major problem with
the Apache 2.0 license is that it is frequently seen as being
incompatible with the GPL2 license. Although many people consider it
to be compatible with
On 23 March 2017 at 18:04, Salz, Rich via openssl-dev <
openssl-dev@openssl.org> wrote:
> > The new license also conflicts with the GPLv2. This was immediately
> brought
> > up as a serious problem when this discussion began in July of 2015. It
> > appears that the feedback that the APL does
On 23/03/17 10:13, Mody, Darshan (Darshan) wrote:
> Matt,
>
> Even after accounting for the EC_KEY we still observe some leak. The
> leak started after we started using supporting EC with callback
> SSL_set_tmp_ecdh_callback().
>
> The core dump shows the string data of the far-end
Matt,
Even after accounting for the EC_KEY we still observe some leak. The leak
started after we started using supporting EC with callback
SSL_set_tmp_ecdh_callback().
The core dump shows the string data of the far-end certificates. I cannot pin
point the code in openssl with this regard.
On 23/03/17 04:35, Mody, Darshan (Darshan) wrote:
> Matt,
>
> But openssl does not release the memory when it has duplicated the EC Key
> which comes from the application
You mean it doesn't free the return value from the callback?
Unfortunately SSL_set_tmp_ecdh_callback() is undocumented so
--On Friday, March 24, 2017 1:37 AM + Peter Waltenberg
wrote:
OpenSSL has a LOT of commercial users and contributors. Apache2 they can
live with, GPL not so much.
There's also the point that many of the big consumers (like Apache :))
are also under Apache2.
Least
Apache license is fine for me, while GPL could be problematic. Incompatibility
with GPLv2 is not a problem for us.
If it is a problem for somebody - feel free to explain the details. Though I
think the decision has been made, and the majority is OK with it.
Regards,
Uri
Sent from my iPhone
OpenSSL has a LOT of commercial users and contributors. Apache2 they can live with, GPL not so much. There's also the point that many of the big consumers (like Apache :)) are also under Apache2. Least possible breakage and I think it's a reasonable compromise. Of course I am biased because I
Hi all
Our next "Code Health Tuesday" event will be on Tuesday 28th March.
We've seen some great contributions during our last two events with many
significant improvements merged as a result. We'd like to continue that
trend with our next theme - documentation.
Just find some missing
--On Thursday, March 23, 2017 11:41 AM -0400 Rich Salz
wrote:
If you have contributed code to OpenSSL, we'd like you to take a look
at our licensing website, https://license.openssl.org and give approval
to our converting to the Apache Software License.
You can find more
> The major problem with the existing license is that it conflicts with the
> GPLv2.
Well, it's one of the problems. The others includes that it is non-standard,
and has an advertising clause.
> The new license also conflicts with the GPLv2. This was immediately brought
> up as a serious
Can you further elaborate?
What we did is to create a TLS connection and with invalid certificates from
the client and server on verification would reject the certificate. The cipher
negotiated was ECDHE cipher between client and server.
This was done with load (multiple while 1 script trying
On 23/03/17 13:19, Mody, Darshan (Darshan) wrote:
> Can you further elaborate?
>
> What we did is to create a TLS connection and with invalid
> certificates from the client and server on verification would reject
> the certificate. The cipher negotiated was ECDHE cipher between
> client and
If you have contributed code to OpenSSL, we'd like you to take a look
at our licensing website, https://license.openssl.org and give approval
to our converting to the Apache Software License.
You can find more details at our most recent blog entry,
https://www.openssl.org/blog
Over the next
Matt,
Below is the scenario.
1. Have server open a listen socket which always validates the client
certificate and chain.
2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl
from app is cleaned up by the app.
3. Connect client with certificates that server does not
Thanks Richard and Matt,
I will patch it and send the patch. It will take me couple of days.
Regards
Darshan
-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of Richard
Levitte
Sent: Thursday, March 23, 2017 7:31 PM
To: openssl-dev@openssl.org
I think that Matt is asking for example code that exhibits this leak.
You could patch apps/s_server.c with your callback, or ssl/ssltest.c,
and give us that patch.
The reason is that we can't know what assumptions you're going with in
your callback or application, so if we code an example
I'm only a minor contributor. But as I regularly use OpenSSL in other
projects, I wholeheartedly embrace this change. Thank you for the
effort you are putting in to make this happen.
On Thu, Mar 23, 2017 at 10:41 AM, Rich Salz wrote:
> If you have contributed code to OpenSSL,
Should not openssl release memory from app.
Some like below
/* Duplicate the ECDH structure. */
if (ecdhp == NULL) {
SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB);
goto err;
}
if
19 matches
Mail list logo