From steffen at sdaoden.eu Wed Mar 1 15:43:18 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 01 Mar 2017 16:43:18 +0100 Subject: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux) Message-ID: <20170301154318.U0FZ5%steffen@sdaoden.eu> Hello. I am sorry, but i have no github account. Maybe it is possible to have some @bug address which creates issues automatically? I see this on ? openssl version OpenSSL 1.0.2k 26 Jan 2017 ? /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl version OpenSSL 1.1.0 25 Aug 2016 ? openssl verify -verbose -CAfile SOME-FILE SOME-CERT SOME-FILE: OK ? openssl verify -verbose -CApath SOME-FILE SOME-CERT error 20 at 0 depth lookup:unable to get local issuer certificate I look into apps/apps.c, but i cannot tell why this does not bail out when the directory is found to be a file. Ciao, --steffen From rsalz at akamai.com Wed Mar 1 16:03:46 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 1 Mar 2017 16:03:46 +0000 Subject: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux) In-Reply-To: <20170301154318.U0FZ5%steffen@sdaoden.eu> References: <20170301154318.U0FZ5%steffen@sdaoden.eu> Message-ID: <9f399a4828e4479d895aad00cd832ad1@usma1ex-dag1mb1.msg.corp.akamai.com> > I am sorry, but i have no github account. Maybe it is possible to have some > @bug address which creates issues automatically? Nah, too much spam will happen :( Posting to openssl-dev is fine. > ? openssl version > OpenSSL 1.0.2k 26 Jan 2017 > ? /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl version > OpenSSL 1.1.0 25 Aug 2016 So this happens on both 1.0.2 and 1.1.0? Does the following patch fix it for 1.1.0? ; git diff diff --git a/apps/opt.c b/apps/opt.c index 499a0b5..4547da1 100644 --- a/apps/opt.c +++ b/apps/opt.c @@ -661,7 +661,8 @@ int opt_next(void) return -1; case '<': /* Input file. */ - if (strcmp(arg, "-") == 0 || app_access(arg, R_OK) >= 0) + if (strcmp(arg, "-") == 0 + || (!app_isdir(arg) && app_access(arg, R_OK) >= 0)) break; BIO_printf(bio_err, "%s: Cannot open input file %s, %s\n", From steffen at sdaoden.eu Wed Mar 1 16:13:24 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 01 Mar 2017 17:13:24 +0100 Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations Message-ID: <20170301161324.SoyQL%steffen@sdaoden.eu> Oh, hello again, now i finally have updated (without "make tests?") and it seems i now have to fill in $LD_LIBRARY_PATH to get running: $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl ... libssl.so.1.1 => not found libcrypto.so.1.1 => not found This is new behaviour, until now the installation was always self-contained when configured via ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared I think this should at least be noted in CHANGES or so. Ciao, --steffen From rsalz at akamai.com Wed Mar 1 16:16:53 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 1 Mar 2017 16:16:53 +0000 Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations In-Reply-To: <20170301161324.SoyQL%steffen@sdaoden.eu> References: <20170301161324.SoyQL%steffen@sdaoden.eu> Message-ID: <3c2899bf39224b628014037a2bbaaa6c@usma1ex-dag1mb1.msg.corp.akamai.com> > This is new behaviour, until now the installation was always self-contained > when configured via > > ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared Did you install the libraries in a standard place? > I think this should at least be noted in CHANGES or so. I don't think so. I think the libs weren't installed. From steffen at sdaoden.eu Wed Mar 1 16:46:40 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 01 Mar 2017 17:46:40 +0100 Subject: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux) In-Reply-To: <9f399a4828e4479d895aad00cd832ad1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170301154318.U0FZ5%steffen@sdaoden.eu> <9f399a4828e4479d895aad00cd832ad1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20170301164640.55lz8%steffen@sdaoden.eu> Sorry for the late reply, this really is a slow machine (and i cleanup again completely anything once it is installed, _and_ the tests compile a long time even if not run).. "Salz, Rich" wrote: |> I am sorry, but i have no github account. Maybe it is possible to \ |> have some |> @bug address which creates issues automatically? | |Nah, too much spam will happen :( Posting to openssl-dev is fine. Ok, good. |> ? openssl version |> OpenSSL 1.0.2k 26 Jan 2017 |> ? /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl version |> OpenSSL 1.1.0 25 Aug 2016 | |So this happens on both 1.0.2 and 1.1.0? | |Does the following patch fix it for 1.1.0? No, not that i know. But this -- thanks -- lead me to the following, which is the KISS that you want? Ciao! diff --git a/apps/apps.c b/apps/apps.c index 216bc797d..3afbbaef2 100644 --- a/apps/apps.c +++ b/apps/apps.c @@ -1221,7 +1221,8 @@ X509_STORE *setup_verify(const char *CAfile, const char *CApath, int noCAfile, i if (lookup == NULL) goto end; if (CApath) { - if (!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) { + if (!app_isdir(CApath) || + !X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) { BIO_printf(bio_err, "Error loading directory %s\n", CApath); goto end; } --steffen From steffen at sdaoden.eu Wed Mar 1 16:50:32 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 01 Mar 2017 17:50:32 +0100 Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations In-Reply-To: <3c2899bf39224b628014037a2bbaaa6c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20170301161324.SoyQL%steffen@sdaoden.eu> <3c2899bf39224b628014037a2bbaaa6c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20170301165032.8jhWg%steffen@sdaoden.eu> "Salz, Rich" wrote: |> This is new behaviour, until now the installation was always self-contain\ |> ed |> when configured via |> |> ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared | |Did you install the libraries in a standard place? | |> I think this should at least be noted in CHANGES or so. | |I don't think so. I think the libs weren't installed. Yes, also in my opinion the old behaviour was much, much better. --steffen From openssl-users at dukhovni.org Wed Mar 1 17:26:00 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Mar 2017 12:26:00 -0500 Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations In-Reply-To: <20170301161324.SoyQL%steffen@sdaoden.eu> References: <20170301161324.SoyQL%steffen@sdaoden.eu> Message-ID: <931B809C-BBAB-4020-8FDB-09F46E49D12B@dukhovni.org> > On Mar 1, 2017, at 11:13 AM, Steffen Nurpmeso wrote: > > $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl > ... > libssl.so.1.1 => not found > libcrypto.so.1.1 => not found > > This is new behaviour, until now the installation was always > self-contained when configured via > > ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared I sure hope that "$()" was in fact "${}", the former only works in Makefiles, and means something quite different in POSIX shells. You need an "RPATH" setting in the linker flags for the shared libraries to be found in in $PREFIX/lib. Perhaps: ./config --prefix="${MYPREFIX}" -R "${MYPREFIX}/lib" ... Or "-rpath ..." or "-Wl,-R,..." ... -- Viktor. From openssl-users at dukhovni.org Wed Mar 1 17:44:18 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 1 Mar 2017 12:44:18 -0500 Subject: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux) In-Reply-To: <20170301164640.55lz8%steffen@sdaoden.eu> References: <20170301154318.U0FZ5%steffen@sdaoden.eu> <9f399a4828e4479d895aad00cd832ad1@usma1ex-dag1mb1.msg.corp.akamai.com> <20170301164640.55lz8%steffen@sdaoden.eu> Message-ID: > On Mar 1, 2017, at 11:46 AM, Steffen Nurpmeso wrote: > > No, not that i know. But this -- thanks -- lead me to the > following, which is the KISS that you want? > Ciao! > > diff --git a/apps/apps.c b/apps/apps.c > index 216bc797d..3afbbaef2 100644 > --- a/apps/apps.c > +++ b/apps/apps.c > @@ -1221,7 +1221,8 @@ X509_STORE *setup_verify(const char *CAfile, const char *CApath, int noCAfile, i > if (lookup == NULL) > goto end; > if (CApath) { > - if (!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) { > + if (!app_isdir(CApath) || > + !X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM)) { > BIO_printf(bio_err, "Error loading directory %s\n", CApath); > goto end; > } We may need to be careful. With OpenSSL <= 1.0.2, one way to suppress the built-in default CApath was to set "-CApath" to a non-existent directory. Users may have scripts relying on this behaviour. Now with 1.1.0 on some platforms OpenSSL already rejects non-existent directories, and we also provide a "-no-CAfile" option, but this change will extend the change to what is likely our most popular platform. So it will at least deserve a comment in the "NEWS"/"CHANGES" files. -- Viktor. From levitte at openssl.org Wed Mar 1 19:14:39 2017 From: levitte at openssl.org (Richard Levitte) Date: Wed, 01 Mar 2017 20:14:39 +0100 (CET) Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations In-Reply-To: <20170301165032.8jhWg%steffen@sdaoden.eu> References: <20170301161324.SoyQL%steffen@sdaoden.eu> <3c2899bf39224b628014037a2bbaaa6c@usma1ex-dag1mb1.msg.corp.akamai.com> <20170301165032.8jhWg%steffen@sdaoden.eu> Message-ID: <20170301.201439.1849973414143723796.levitte@openssl.org> In message <20170301165032.8jhWg%steffen at sdaoden.eu> on Wed, 01 Mar 2017 17:50:32 +0100, Steffen Nurpmeso said: steffen> "Salz, Rich" wrote: steffen> |> This is new behaviour, until now the installation was always self-contain\ steffen> |> ed steffen> |> when configured via steffen> |> steffen> |> ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared steffen> | steffen> |Did you install the libraries in a standard place? steffen> | steffen> |> I think this should at least be noted in CHANGES or so. steffen> | steffen> |I don't think so. I think the libs weren't installed. steffen> steffen> Yes, also in my opinion the old behaviour was much, much better. I very much disagree. We have had bug reports as well as cases of our own because a new compilation that you want to test picked up previously installed versions of the libraries (usually an older version). The reason for doing so previously was because we installed the libraries in non-standard locations by default. Since OpenSSL 1.1.0 and on is installing in standard locations by default, we don't have to use these mechanisms for a default build. With that, we realised that choosing to use DT_RPATH, DT_RUNPATH (they are different) or whatever isn't really our decision to make, but the decision of the packager or the individual user, so we've handed the decision to you. For the GNU toolchain, I'd recommend configuring with something like this (from memory, I might be fuzzy in the details): -Wl,--enable-new-dtags -rpath '$(LIBRPATH)' LIBRPATH is a convenience Makefile variable that gets correctly set to the configured shared library installation directory, meant for exactly this sort of situation. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From steffen at sdaoden.eu Wed Mar 1 21:52:36 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 01 Mar 2017 22:52:36 +0100 Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations In-Reply-To: <931B809C-BBAB-4020-8FDB-09F46E49D12B@dukhovni.org> References: <20170301161324.SoyQL%steffen@sdaoden.eu> <931B809C-BBAB-4020-8FDB-09F46E49D12B@dukhovni.org> Message-ID: <20170301215236.NUtNB%steffen@sdaoden.eu> Good evening. Viktor Dukhovni wrote: |> On Mar 1, 2017, at 11:13 AM, Steffen Nurpmeso wrote: |> |> $ ldd /home/steffen/usr/opt/.ssl-1.1.0/bin/openssl |> ... |> libssl.so.1.1 => not found |> libcrypto.so.1.1 => not found |> |> This is new behaviour, until now the installation was always |> self-contained when configured via |> |> ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared | |I sure hope that "$()" was in fact "${}", the former only |works in Makefiles, and means something quite different |in POSIX shells. No it is a snippet from a makefile, of course. |You need an "RPATH" setting in the linker flags for the shared |libraries to be found in in $PREFIX/lib. Perhaps: If my tortured ears finally hear, then. You are saying this never was standard behaviour? Oh!?! Well, then i am sorry, it could indeed be that i never ran the binaries in there, but only use this one for v1.1.0 link testing, and then, there, the linker path is adjusted automatically (by my configuration script). It may be a crappy comment, but if i ldd(1) ~/usr/opt/.ressl/bin/openssl then this just works, and the make rule is almost identical: libressl: cd libressl.tar_bomb_git &&\ if [ -f NULL ]; then git checkout `cat NULL`; fi &&\ ./configure --prefix=$(MYPREFIX) &&\ make &&\ make check &&\ $(SUDO) make install;\ { git clean -fxd; git reset --hard HEAD;\ git checkout arena-manager-null; } >/dev/null But thanks, i did not know that i can pass additional flags to ./config! Thanks to Matt Caswell i think, if i recall correctly, i now know about "make install_sw && make install_ssldirs", and maybe in a not too distant future i get it right! --steffen From steffen at sdaoden.eu Wed Mar 1 22:05:45 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 01 Mar 2017 23:05:45 +0100 Subject: [openssl-dev] [Bug] apps: -CApath does not fail for non-directories (on Linux) In-Reply-To: References: <20170301154318.U0FZ5%steffen@sdaoden.eu> <9f399a4828e4479d895aad00cd832ad1@usma1ex-dag1mb1.msg.corp.akamai.com> <20170301164640.55lz8%steffen@sdaoden.eu> Message-ID: <20170301220545.l78fC%steffen@sdaoden.eu> Hello again, Viktor Dukhovni wrote: |> On Mar 1, 2017, at 11:46 AM, Steffen Nurpmeso wrote: |> No, not that i know. But this -- thanks -- lead me to the |> following, which is the KISS that you want? ... |> diff --git a/apps/apps.c b/apps/apps.c |> index 216bc797d..3afbbaef2 100644 |> --- a/apps/apps.c |> +++ b/apps/apps.c |> @@ -1221,7 +1221,8 @@ X509_STORE *setup_verify(const char *CAfile, \ |> const char *CApath, int noCAfile, i |> if (lookup == NULL) |> goto end; |> if (CApath) { |> - if (!X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_PEM))\ |> { |> + if (!app_isdir(CApath) || |> + !X509_LOOKUP_add_dir(lookup, CApath, X509_FILETYPE_P\ |> EM)) { |> BIO_printf(bio_err, "Error loading directory %s\n", \ |> CApath); |> goto end; |>} | |We may need to be careful. With OpenSSL <= 1.0.2, one way to suppress the |built-in default CApath was to set "-CApath" to a non-existent directory. |Users may have scripts relying on this behaviour. Now with 1.1.0 on some |platforms OpenSSL already rejects non-existent directories, and we also |provide a "-no-CAfile" option, but this change will extend the change to |what is likely our most popular platform. | |So it will at least deserve a comment in the "NEWS"/"CHANGES" files. I understand that this is a "lingering" configuration, which is inspected on the fly as a last (or second last, if there is SSL_CTX_set_default_verify_paths(3). In fact i don't know, the documentation is horrific! E.g., just today i have implemented some *{smime,ssl}-ca-flags*, mostly to be able to provide X509_V_FLAG_PARTIAL_CHAIN, but you know you can't find just any X509_STORE_set_flags(_not_ 3) at all, it is, again, _horrific_. I for one, as someone unrelated, now that you have so many sponsors, i really wonder why you don't spend a little bit of money to some crypto nerd student(s) who really need(s) it in order to improve it. Really, and honestly.) resort. But for an application that does a one-shot check i would at least expect a message that leads into the right direction, at least with -verbose. I for one _of course_ looked for X509_LOOKUP_add_dir() first, but i gave up after the second indirection. If you would ask me, i surely would add a X509_FILETYPE_CHECK_OR_ERROR or similar flag to get the synchronous checks. But who am i. --steffen From steffen at sdaoden.eu Wed Mar 1 22:17:03 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 01 Mar 2017 23:17:03 +0100 Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations In-Reply-To: <20170301.201439.1849973414143723796.levitte@openssl.org> References: <20170301161324.SoyQL%steffen@sdaoden.eu> <3c2899bf39224b628014037a2bbaaa6c@usma1ex-dag1mb1.msg.corp.akamai.com> <20170301165032.8jhWg%steffen@sdaoden.eu> <20170301.201439.1849973414143723796.levitte@openssl.org> Message-ID: <20170301221703.tFwPU%steffen@sdaoden.eu> Hello, Richard Levitte wrote: |In message <20170301165032.8jhWg%steffen at sdaoden.eu> on Wed, 01 Mar \ |2017 17:50:32 +0100, Steffen Nurpmeso said: | |steffen> "Salz, Rich" wrote: |steffen> |> This is new behaviour, until now the installation was \ |always self-contain\ |steffen> |> ed |steffen> |> when configured via |steffen> |> |steffen> |> ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared |steffen> | |steffen> |Did you install the libraries in a standard place? |steffen> | |steffen> |> I think this should at least be noted in CHANGES or so. |steffen> | |steffen> |I don't think so. I think the libs weren't installed. |steffen> |steffen> Yes, also in my opinion the old behaviour was much, much better. | |I very much disagree. We have had bug reports as well as cases of our |own because a new compilation that you want to test picked up |previously installed versions of the libraries (usually an older |version). The reason for doing so previously was because we installed |the libraries in non-standard locations by default. That unpuzzles me a little bit -- this behaviour did exist. Good. |Since OpenSSL 1.1.0 and on is installing in standard locations by |default, we don't have to use these mechanisms for a default build. |With that, we realised that choosing to use DT_RPATH, DT_RUNPATH (they |are different) or whatever isn't really our decision to make, but the |decision of the packager or the individual user, so we've handed the |decision to you. | |For the GNU toolchain, I'd recommend configuring with something like |this (from memory, I might be fuzzy in the details): | | -Wl,--enable-new-dtags -rpath '$(LIBRPATH)' | |LIBRPATH is a convenience Makefile variable that gets correctly set to |the configured shared library installation directory, meant for |exactly this sort of situation. The latter (DT_RUNPATH) does not overwrite $LD_LIBRARY_PATH, yes, when i reported the dynamic link test failures a while back i have seen that and also added support for this new linker flag to my software. It is i think off-topic that now new environment variables come up that makes me wonder why the LD_PRELOAD .. DT_RPATH .. LD_LIBRARY_PATH chain has ever been declared deprecated. LIBRPATH i did not know about yet, thanks for the pointer, i will read about it. Yes, i mean, i just didn't know this, it is not mentioned anywhere (i think that would well be worth in entry in INSTALL), and i really would have sworn that it worked in the past. Thank you, and Ciao! --steffen From levitte at openssl.org Wed Mar 1 22:25:20 2017 From: levitte at openssl.org (Richard Levitte) Date: Wed, 01 Mar 2017 23:25:20 +0100 (CET) Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations In-Reply-To: <20170301221703.tFwPU%steffen@sdaoden.eu> References: <20170301165032.8jhWg%steffen@sdaoden.eu> <20170301.201439.1849973414143723796.levitte@openssl.org> <20170301221703.tFwPU%steffen@sdaoden.eu> Message-ID: <20170301.232520.1329239735171553967.levitte@openssl.org> In message <20170301221703.tFwPU%steffen at sdaoden.eu> on Wed, 01 Mar 2017 23:17:03 +0100, Steffen Nurpmeso said: steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere steffen> (i think that would well be worth in entry in INSTALL), and steffen> i really would have sworn that it worked in the past. I was actually surprised to find this undocumented. I could have sworn I'd done so, but apparently, I only did in a commit message: commit fad599f7f147ee71e5581211fb654c2c8c491cd8 Author: Richard Levitte Date: Wed Oct 12 17:05:35 2016 +0200 Remove automatic RPATH - add user rpath support Make Configure recognise -rpath and -R to support user added rpaths for OSF1 and Solaris. For convenience, add a variable LIBRPATH in the Unix Makefile, which the users can use as follows: ./config [options] -Wl,-rpath,\$(LIBRPATH) Reviewed-by: Rich Salz I'll go add a note now... Sorry Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From steffen at sdaoden.eu Wed Mar 1 22:46:18 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Wed, 01 Mar 2017 23:46:18 +0100 Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations In-Reply-To: <20170301.232520.1329239735171553967.levitte@openssl.org> References: <20170301165032.8jhWg%steffen@sdaoden.eu> <20170301.201439.1849973414143723796.levitte@openssl.org> <20170301221703.tFwPU%steffen@sdaoden.eu> <20170301.232520.1329239735171553967.levitte@openssl.org> Message-ID: <20170301224618.SIlBt%steffen@sdaoden.eu> Hello. Richard Levitte wrote: |In message <20170301221703.tFwPU%steffen at sdaoden.eu> on Wed, 01 Mar \ |2017 23:17:03 +0100, Steffen Nurpmeso said: | |steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere |steffen> (i think that would well be worth in entry in INSTALL), and |steffen> i really would have sworn that it worked in the past. | |I was actually surprised to find this undocumented. I could have |sworn I'd done so, but apparently, I only did in a commit message: | | commit fad599f7f147ee71e5581211fb654c2c8c491cd8 | Author: Richard Levitte | Date: Wed Oct 12 17:05:35 2016 +0200 | | Remove automatic RPATH - add user rpath support | | Make Configure recognise -rpath and -R to support user added rpaths | for OSF1 and Solaris. For convenience, add a variable LIBRPATH \ | in the | Unix Makefile, which the users can use as follows: | | ./config [options] -Wl,-rpath,\$(LIBRPATH) | | Reviewed-by: Rich Salz | |I'll go add a note now... Thank you very much. Have a good time. --steffen From levitte at openssl.org Wed Mar 1 22:46:34 2017 From: levitte at openssl.org (Richard Levitte) Date: Wed, 01 Mar 2017 23:46:34 +0100 (CET) Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations In-Reply-To: <20170301221703.tFwPU%steffen@sdaoden.eu> References: <20170301165032.8jhWg%steffen@sdaoden.eu> <20170301.201439.1849973414143723796.levitte@openssl.org> <20170301221703.tFwPU%steffen@sdaoden.eu> Message-ID: <20170301.234634.1470347687969654613.levitte@openssl.org> In message <20170301221703.tFwPU%steffen at sdaoden.eu> on Wed, 01 Mar 2017 23:17:03 +0100, Steffen Nurpmeso said: steffen> Hello, steffen> steffen> Richard Levitte wrote: steffen> |In message <20170301165032.8jhWg%steffen at sdaoden.eu> on Wed, 01 Mar \ steffen> |2017 17:50:32 +0100, Steffen Nurpmeso said: steffen> | steffen> |steffen> "Salz, Rich" wrote: steffen> |steffen> |> This is new behaviour, until now the installation was \ steffen> |always self-contain\ steffen> |steffen> |> ed steffen> |steffen> |> when configured via steffen> |steffen> |> steffen> |steffen> |> ./config --prefix=$(MYPREFIX) zlib-dynamic no-hw shared steffen> |steffen> | steffen> |steffen> |Did you install the libraries in a standard place? steffen> |steffen> | steffen> |steffen> |> I think this should at least be noted in CHANGES or so. steffen> |steffen> | steffen> |steffen> |I don't think so. I think the libs weren't installed. steffen> |steffen> steffen> |steffen> Yes, also in my opinion the old behaviour was much, much better. steffen> | steffen> |I very much disagree. We have had bug reports as well as cases of our steffen> |own because a new compilation that you want to test picked up steffen> |previously installed versions of the libraries (usually an older steffen> |version). The reason for doing so previously was because we installed steffen> |the libraries in non-standard locations by default. steffen> steffen> That unpuzzles me a little bit -- this behaviour did exist. Good. steffen> steffen> |Since OpenSSL 1.1.0 and on is installing in standard locations by steffen> |default, we don't have to use these mechanisms for a default build. steffen> |With that, we realised that choosing to use DT_RPATH, DT_RUNPATH (they steffen> |are different) or whatever isn't really our decision to make, but the steffen> |decision of the packager or the individual user, so we've handed the steffen> |decision to you. steffen> | steffen> |For the GNU toolchain, I'd recommend configuring with something like steffen> |this (from memory, I might be fuzzy in the details): steffen> | steffen> | -Wl,--enable-new-dtags -rpath '$(LIBRPATH)' steffen> | steffen> |LIBRPATH is a convenience Makefile variable that gets correctly set to steffen> |the configured shared library installation directory, meant for steffen> |exactly this sort of situation. steffen> steffen> The latter (DT_RUNPATH) does not overwrite $LD_LIBRARY_PATH, yes, steffen> when i reported the dynamic link test failures a while back i have steffen> seen that and also added support for this new linker flag to my steffen> software. It is i think off-topic that now new environment steffen> variables come up that makes me wonder why the LD_PRELOAD .. steffen> DT_RPATH .. LD_LIBRARY_PATH chain has ever been declared steffen> deprecated. steffen> steffen> LIBRPATH i did not know about yet, thanks for the pointer, i will steffen> read about it. steffen> Yes, i mean, i just didn't know this, it is not mentioned anywhere steffen> (i think that would well be worth in entry in INSTALL), and steffen> i really would have sworn that it worked in the past. steffen> steffen> Thank you, and steffen> Ciao! I've added a change with documentation: https://github.com/openssl/openssl/pull/2818 Please go in and comment, or if you don't have a github account, feel free to comment here. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From steffen at sdaoden.eu Thu Mar 2 14:11:22 2017 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 02 Mar 2017 15:11:22 +0100 Subject: [openssl-dev] [Bug, maybe] [master] bin/* no longer find their libraries if installed in non-default locations In-Reply-To: <20170301.234634.1470347687969654613.levitte@openssl.org> References: <20170301165032.8jhWg%steffen@sdaoden.eu> <20170301.201439.1849973414143723796.levitte@openssl.org> <20170301221703.tFwPU%steffen@sdaoden.eu> <20170301.234634.1470347687969654613.levitte@openssl.org> Message-ID: <20170302141122.gaM4B%steffen@sdaoden.eu> Hello. Richard Levitte wrote: |I've added a change with documentation: | |https://github.com/openssl/openssl/pull/2818 | |Please go in and comment, or if you don't have a github account, feel |free to comment here. Thank you, i have added it to my makefile 1:1. Ciao! --steffen From emilia at openssl.org Fri Mar 3 10:39:29 2017 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Fri, 03 Mar 2017 10:39:29 +0000 Subject: [openssl-dev] Code Health Tuesday: results and next event (March 14th) Message-ID: Hi developers, Here's a summary of our Code Health Tuesday. The team and contributors created 37 pull requests ( https://github.com/openssl/openssl/pulls?q=is%3Apr%20label%3Acode-health%20). We removed ca 4000 lines of code: entire dead files, duplicate tests, workarounds for no-longer-supported platforms, and optimizations that no longer matter. Thanks everyone who participated! We're pretty excited about this outcome so we'll do it again in two weeks' time (March 14th). I'm thinking we should continue with the "coverage" theme but broaden the focus from simply deleting useless code to really analyzing why something isn't covered, and adding missing tests where appropriate. Meanwhile, you can keep those pull requests coming every day! Feel free to continue to flag cleanup pulls with "code health", to draw our attention. Thank you! Emilia -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Thu Mar 9 12:58:20 2017 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Thu, 9 Mar 2017 05:58:20 -0700 Subject: [openssl-dev] Openssl 1.0.2 stable SNAP 20170309 issue Message-ID: <20170309125820.GA27757@doctor.nl2k.ab.ca> Script started on Thu Mar 9 05:45:36 2017 root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170309 # make making all in crypto... making all in crypto/objects... making all in crypto/md4... making all in crypto/md5... making all in crypto/sha... making all in crypto/mdc2... making all in crypto/hmac... making all in crypto/ripemd... making all in crypto/whrlpool... making all in crypto/des... making all in crypto/aes... making all in crypto/rc2... making all in crypto/rc4... making all in crypto/idea... making all in crypto/bf... making all in crypto/cast... making all in crypto/camellia... making all in crypto/seed... making all in crypto/modes... making all in crypto/bn... making all in crypto/ec... making all in crypto/rsa... making all in crypto/dsa... making all in crypto/ecdsa... making all in crypto/dh... making all in crypto/ecdh... making all in crypto/dso... making all in crypto/engine... making all in crypto/buffer... making all in crypto/bio... making all in crypto/stack... making all in crypto/lhash... making all in crypto/rand... making all in crypto/err... making all in crypto/evp... making all in crypto/asn1... making all in crypto/pem... making all in crypto/x509... making all in crypto/x509v3... making all in crypto/conf... making all in crypto/txt_db... making all in crypto/pkcs7... making all in crypto/pkcs12... making all in crypto/comp... making all in crypto/ocsp... making all in crypto/ui... making all in crypto/krb5... making all in crypto/cms... making all in crypto/pqueue... making all in crypto/ts... making all in crypto/jpake... making all in crypto/srp... making all in crypto/store... making all in crypto/cmac... if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libcrypto.so.1.0.0); fi `libcrypto.so.1.0.0' is up to date. making all in engines... echo making all in engines/ccgost... making all in ssl... if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libssl.so.1.0.0); fi `libssl.so.1.0.0' is up to date. making all in apps... /usr/local/bin/clang39 -DMONOLITH -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c enc.c -o enc.o enc.c:93:5: error: use of undeclared identifier 'cipher' cipher = EVP_get_cipherbyname(name->name); ^ enc.c:94:9: error: use of undeclared identifier 'cipher' if (cipher == NULL || ^ enc.c:95:31: error: use of undeclared identifier 'cipher' (EVP_CIPHER_flags(cipher) & EVP_CIPH_FLAG_AEAD_CIPHER) != 0 || ^ enc.c:96:29: error: use of undeclared identifier 'cipher' EVP_CIPHER_mode(cipher) == EVP_CIPH_XTS_MODE) ^ 4 errors generated. *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170309/apps *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170309 root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170309 # exzit exzit: Command not found. root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170309 # exit exit Script done on Thu Mar 9 05:46:27 2017 Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism God is dead! Yahweh lives! Jesus his only begotten Son is the Risen Saviour!! From rsalz at akamai.com Thu Mar 9 13:02:01 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 9 Mar 2017 13:02:01 +0000 Subject: [openssl-dev] Openssl 1.0.2 stable SNAP 20170309 issue In-Reply-To: <20170309125820.GA27757@doctor.nl2k.ab.ca> References: <20170309125820.GA27757@doctor.nl2k.ab.ca> Message-ID: Already fixed. From doctor at doctor.nl2k.ab.ca Sat Mar 11 06:38:06 2017 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 10 Mar 2017 23:38:06 -0700 Subject: [openssl-dev] Openssl 1.0.2 snap STABLE 20170311 issue Message-ID: <20170311063806.GA39422@doctor.nl2k.ab.ca> Script started on Fri Mar 10 23:31:39 2017 You have mail. root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170311 # make making all in crypto... making all in crypto/objects... making all in crypto/md4... making all in crypto/md5... making all in crypto/sha... making all in crypto/mdc2... making all in crypto/hmac... making all in crypto/ripemd... making all in crypto/whrlpool... making all in crypto/des... making all in crypto/aes... making all in crypto/rc2... making all in crypto/rc4... making all in crypto/idea... making all in crypto/bf... making all in crypto/cast... making all in crypto/camellia... making all in crypto/seed... making all in crypto/modes... making all in crypto/bn... making all in crypto/ec... making all in crypto/rsa... making all in crypto/dsa... making all in crypto/ecdsa... making all in crypto/dh... making all in crypto/ecdh... making all in crypto/dso... making all in crypto/engine... making all in crypto/buffer... making all in crypto/bio... making all in crypto/stack... making all in crypto/lhash... making all in crypto/rand... making all in crypto/err... making all in crypto/evp... making all in crypto/asn1... making all in crypto/pem... making all in crypto/x509... making all in crypto/x509v3... making all in crypto/conf... making all in crypto/txt_db... making all in crypto/pkcs7... making all in crypto/pkcs12... making all in crypto/comp... making all in crypto/ocsp... making all in crypto/ui... making all in crypto/krb5... making all in crypto/cms... making all in crypto/pqueue... making all in crypto/ts... making all in crypto/jpake... making all in crypto/srp... making all in crypto/store... making all in crypto/cmac... if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libcrypto.so.1.0.0); fi `libcrypto.so.1.0.0' is up to date. making all in engines... echo making all in engines/ccgost... making all in ssl... /usr/local/bin/clang39 -I../crypto -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c ssl_rsa.c -o ssl_rsa.o ssl_rsa.c:105:46: error: no member named 'default_passwd_callback' in 'struct ssl_st' x = PEM_read_bio_X509(in, NULL, ssl->default_passwd_callback, ~~~ ^ ssl_rsa.c:106:36: error: no member named 'default_passwd_callback_userdata' in 'struct ssl_st' ssl->default_passwd_callback_userdata); ~~~ ^ ssl_rsa.c:264:47: error: no member named 'default_passwd_callback' in 'struct ssl_st' ssl->default_passwd_callback, ~~~ ^ ssl_rsa.c:265:47: error: no member named 'default_passwd_callback_userdata' in 'struct ssl_st' ssl->default_passwd_callback_userdata); ~~~ ^ ssl_rsa.c:337:45: error: no member named 'default_passwd_callback' in 'struct ssl_st' ssl->default_passwd_callback, ~~~ ^ ssl_rsa.c:338:45: error: no member named 'default_passwd_callback_userdata' in 'struct ssl_st' ssl->default_passwd_callback_userdata); ~~~ ^ 6 errors generated. *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170311/ssl *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170311 root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170311 # exit exit Script done on Fri Mar 10 23:36:32 2017 Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism God is dead! Yahweh lives! Jesus his only begotten Son is the Risen Saviour!! From levitte at openssl.org Sat Mar 11 10:28:01 2017 From: levitte at openssl.org (Richard Levitte) Date: Sat, 11 Mar 2017 11:28:01 +0100 (CET) Subject: [openssl-dev] Openssl 1.0.2 snap STABLE 20170311 issue In-Reply-To: <20170311063806.GA39422@doctor.nl2k.ab.ca> References: <20170311063806.GA39422@doctor.nl2k.ab.ca> Message-ID: <20170311.112801.1371123433919726889.levitte@openssl.org> Fixed: commit 6fe43af8d77b119f8af913c284149bca482ee58c Author: Richard Levitte Date: Sat Mar 11 11:19:20 2017 +0100 Revert "Use the callbacks from the SSL object instead of the SSL_CTX object" This shouldn't have been applied to the 1.0.2 branch. This reverts commit 5247c0388610bfdcc8f44b777d75ab681120753d. Reviewed-by: Tim Hudson (Merged from https://github.com/openssl/openssl/pull/2907) Cheers, Richard In message <20170311063806.GA39422 at doctor.nl2k.ab.ca> on Fri, 10 Mar 2017 23:38:06 -0700, The Doctor said: doctor> doctor> Script started on Fri Mar 10 23:31:39 2017 doctor> You have mail. doctor> root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170311 # make doctor> doctor> making all in crypto... doctor> making all in crypto/objects... doctor> making all in crypto/md4... doctor> making all in crypto/md5... doctor> making all in crypto/sha... doctor> making all in crypto/mdc2... doctor> making all in crypto/hmac... doctor> making all in crypto/ripemd... doctor> making all in crypto/whrlpool... doctor> making all in crypto/des... doctor> making all in crypto/aes... doctor> making all in crypto/rc2... doctor> making all in crypto/rc4... doctor> making all in crypto/idea... doctor> making all in crypto/bf... doctor> making all in crypto/cast... doctor> making all in crypto/camellia... doctor> making all in crypto/seed... doctor> making all in crypto/modes... doctor> making all in crypto/bn... doctor> making all in crypto/ec... doctor> making all in crypto/rsa... doctor> making all in crypto/dsa... doctor> making all in crypto/ecdsa... doctor> making all in crypto/dh... doctor> making all in crypto/ecdh... doctor> making all in crypto/dso... doctor> making all in crypto/engine... doctor> making all in crypto/buffer... doctor> making all in crypto/bio... doctor> making all in crypto/stack... doctor> making all in crypto/lhash... doctor> making all in crypto/rand... doctor> making all in crypto/err... doctor> making all in crypto/evp... doctor> making all in crypto/asn1... doctor> making all in crypto/pem... doctor> making all in crypto/x509... doctor> making all in crypto/x509v3... doctor> making all in crypto/conf... doctor> making all in crypto/txt_db... doctor> making all in crypto/pkcs7... doctor> making all in crypto/pkcs12... doctor> making all in crypto/comp... doctor> making all in crypto/ocsp... doctor> making all in crypto/ui... doctor> making all in crypto/krb5... doctor> making all in crypto/cms... doctor> making all in crypto/pqueue... doctor> making all in crypto/ts... doctor> making all in crypto/jpake... doctor> making all in crypto/srp... doctor> making all in crypto/store... doctor> making all in crypto/cmac... doctor> if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libcrypto.so.1.0.0); fi doctor> `libcrypto.so.1.0.0' is up to date. doctor> making all in engines... doctor> echo doctor> doctor> making all in engines/ccgost... doctor> making all in ssl... doctor> /usr/local/bin/clang39 -I../crypto -I.. -I../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c ssl_rsa.c -o ssl_rsa.o doctor> ssl_rsa.c:105:46: error: no member named 'default_passwd_callback' in doctor> 'struct ssl_st' doctor> x = PEM_read_bio_X509(in, NULL, ssl->default_passwd_callback, doctor> ~~~ ^ doctor> ssl_rsa.c:106:36: error: no member named 'default_passwd_callback_userdata' in doctor> 'struct ssl_st' doctor> ssl->default_passwd_callback_userdata); doctor> ~~~ ^ doctor> ssl_rsa.c:264:47: error: no member named 'default_passwd_callback' in doctor> 'struct ssl_st' doctor> ssl->default_passwd_callback, doctor> ~~~ ^ doctor> ssl_rsa.c:265:47: error: no member named 'default_passwd_callback_userdata' in doctor> 'struct ssl_st' doctor> ssl->default_passwd_callback_userdata); doctor> ~~~ ^ doctor> ssl_rsa.c:337:45: error: no member named 'default_passwd_callback' in doctor> 'struct ssl_st' doctor> ssl->default_passwd_callback, doctor> ~~~ ^ doctor> ssl_rsa.c:338:45: error: no member named 'default_passwd_callback_userdata' in doctor> 'struct ssl_st' doctor> ssl->default_passwd_callback_userdata); doctor> ~~~ ^ doctor> 6 errors generated. doctor> *** Error code 1 doctor> doctor> Stop. doctor> make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170311/ssl doctor> *** Error code 1 doctor> doctor> Stop. doctor> make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20170311 doctor> root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20170311 # exit doctor> doctor> exit doctor> doctor> Script done on Fri Mar 10 23:36:32 2017 doctor> doctor> Please fix. doctor> doctor> -- doctor> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca doctor> Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! doctor> http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism doctor> God is dead! Yahweh lives! Jesus his only begotten Son is the Risen Saviour!! doctor> -- doctor> openssl-dev mailing list doctor> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev doctor> From rsalz at akamai.com Sun Mar 12 12:26:05 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 12 Mar 2017 12:26:05 +0000 Subject: [openssl-dev] Code Health Tuesday -- testing! Message-ID: Participate in the second Code Health Tuesday (Mar 14th) Hi OpenSSL developers! In our continuing quest to improve code quality and pay our technical debt, our second Code Health Tuesday is focused on testing. We declare this Tuesday (Mar 14th) Code Health Tuesday. We'll be setting some time aside to improve our codebase by adding tests, fixing things found by static analysis or various "sanitizers," and so on. We invite you all to participate on Github! One easy way to participate is to add sample files that test corner-cases of our X.509, etc., parsing. FAQ: Q: How do I participate? A: Once you've developed your test or fix, create a Github pull request and put "code health" in the title. We'll be monitoring Github for quick turnaround. Q: Which branches should I target? A: Although our first preference is master, test for 1.0.2 our LTS release are also good. Q: Do you have any tools to help? A: We have a coverage report: https://coveralls.io/github/openssl/openssl We also run regular Coverity tests; those currently require registration, but we'll soon be posting them to one of our public mailing lists. Q: Will you do it again? A: This is our second one, so maybe it's a trend :) We have a list of ideas for themed Tuesdays lined up: Document, Test, Refactor, ... -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From darshanmody at avaya.com Mon Mar 13 12:48:59 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Mon, 13 Mar 2017 12:48:59 +0000 Subject: [openssl-dev] CRL implementation caching Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A1023CD@AZ-FFEXMB03.global.avaya.com> Hi, We have modified our codebase to have CRL verification on the incoming certificates. While doing a negative testing with load of certificates I find that the resident memory for the module. My query is when we have CRL verification enabled does openssl caches incoming certificates? Please note that we have set SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF); >From the core file generated I am observing many entries of the far-end certificate serial number. Thanks in Advance Regards Darshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From raja.ashok at huawei.com Tue Mar 14 14:32:27 2017 From: raja.ashok at huawei.com (Raja ashok) Date: Tue, 14 Mar 2017 14:32:27 +0000 Subject: [openssl-dev] Doubt regarding Export keying material Message-ID: Hi All, I am having a doubt in usage of Exporting keying material API (SSL_export_keying_material) in OpenSSL. Please provide your suggestions. As per Section 4 in RFC 5705, context length should be passed as uint16_t to PRF function. In that case we should allow only upto max of 2^16 (65535). So user should not pass more than 65535 value to ?plen? in SSL_export_keying_material right ? Please provide your valuable suggestion on this. I am referring 1.0.2k version of OpenSSL. Thanks & Regards, Ashok ________________________________ [Company_logo] Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ________________________________ ???????????????????????????????????????? ???????????????????????????????????????? ??????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6737 bytes Desc: image001.jpg URL: From darshanmody at avaya.com Wed Mar 15 05:44:54 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Wed, 15 Mar 2017 05:44:54 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> Hi, We have observed memory leak when we register for ECDH callback(SSL_set_tmp_ecdh_callback). While performing negative testing with load we find that the applications starts leaking memory. Further checking the Openssl implementation in the s3_srvr.c file (openssl version 1.0.2). I find that a pointer is not deleted after copying EC_KEY from the application or EC_KEY_new being called. I suspect the below code. if (type & SSL_kEECDH) { const EC_GROUP *group; ecdhp = cert->ecdh_tmp; if (s->cert->ecdh_tmp_auto) { /* Get NID of appropriate shared curve */ int nid = tls1_shared_curve(s, -2); if (nid != NID_undef) ecdhp = EC_KEY_new_by_curve_name(nid); <-- Even memory allocated in this case is not de-allocated. } else if ((ecdhp == NULL) && s->cert->ecdh_tmp_cb) { ecdhp = s->cert->ecdh_tmp_cb(s, <-- Application is responsible for the EC_KEY and its memory SSL_C_IS_EXPORT(s->s3-> tmp.new_cipher), SSL_C_EXPORT_PKEYLENGTH(s-> s3->tmp.new_cipher)); } if (ecdhp == NULL) { al = SSL_AD_HANDSHAKE_FAILURE; SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, SSL_R_MISSING_TMP_ECDH_KEY); goto f_err; } if (s->s3->tmp.ecdh != NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_INTERNAL_ERROR); goto err; } /* Duplicate the ECDH structure. */ if (ecdhp == NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } if (s->cert->ecdh_tmp_auto) ecdh = ecdhp; else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { <-- Once the key is duplicated the memory for the application should be released? SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } s->s3->tmp.ecdh = ecdh; if ((EC_KEY_get0_public_key(ecdh) == NULL) || (EC_KEY_get0_private_key(ecdh) == NULL) || (s->options & SSL_OP_SINGLE_ECDH_USE)) { if (!EC_KEY_generate_key(ecdh)) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } } if (((group = EC_KEY_get0_group(ecdh)) == NULL) || (EC_KEY_get0_public_key(ecdh) == NULL) || (EC_KEY_get0_private_key(ecdh) == NULL)) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) && (EC_GROUP_get_degree(group) > 163)) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, SSL_R_ECGROUP_TOO_LARGE_FOR_CIPHER); goto err; } /* * XXX: For now, we only support ephemeral ECDH keys over named * (not generic) curves. For supported named curves, curve_id is * non-zero. */ if ((curve_id = tls1_ec_nid2curve_id(EC_GROUP_get_curve_name(group))) == 0) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, SSL_R_UNSUPPORTED_ELLIPTIC_CURVE); goto err; } /* * Encode the public key. First check the size of encoding and * allocate memory accordingly. */ encodedlen = EC_POINT_point2oct(group, EC_KEY_get0_public_key(ecdh), POINT_CONVERSION_UNCOMPRESSED, NULL, 0, NULL); encodedPoint = (unsigned char *) OPENSSL_malloc(encodedlen * sizeof(unsigned char)); bn_ctx = BN_CTX_new(); if ((encodedPoint == NULL) || (bn_ctx == NULL)) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_MALLOC_FAILURE); goto err; } encodedlen = EC_POINT_point2oct(group, EC_KEY_get0_public_key(ecdh), POINT_CONVERSION_UNCOMPRESSED, encodedPoint, encodedlen, bn_ctx); if (encodedlen == 0) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } BN_CTX_free(bn_ctx); bn_ctx = NULL; /* * XXX: For now, we only support named (not generic) curves in * ECDH ephemeral key exchanges. In this situation, we need four * additional bytes to encode the entire ServerECDHParams * structure. */ n = 4 + encodedlen; /* * We'll generate the serverKeyExchange message explicitly so we * can set these to NULLs */ r[0] = NULL; r[1] = NULL; r[2] = NULL; r[3] = NULL; } else Thanks for your help in advance Regards Darshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Wed Mar 15 09:50:15 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Wed, 15 Mar 2017 03:50:15 -0600 Subject: [openssl-dev] OpenSSL DRBG in FIPS mode confusion. Message-ID: Hi All, OpenSSL uses 256 bit AES-CTR DRBG as default DRBG in FIPS mode. I have question associated with this. 1. OpenSSL wiki says : Default DRBG is 256-bit CTR AES *using a derivation function* 2. Where as the document http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp1747.pdf mentions "no derivation function" in one place and in another sections mentions both *Section 4 Modes of Operation and Cryptographic Functionality* Random Number Generation; [SP 800?90] DRBG5 Hash DRBG Symmetric key generation Prediction resistance HMAC DRBG, no reseed supported for all variations CTR DRBG (AES), no derivation function *Section 6 Self?test * DRBG KAT CTR_DRBG: AES, 256 bit with and without derivation function Please can any one let me know what is the default behavior? Is there any way to toggle between using and not using derivation function. Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Mar 16 14:35:05 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 16 Mar 2017 14:35:05 +0000 Subject: [openssl-dev] TLSv1.3 draft 19 support Message-ID: <7105c5dd-d70e-5e30-7b3d-1663ffbc2e2f@openssl.org> All, I have just pushed to master the updates necessary for TLSv1.3 draft-19 support. This covers most of the required changes with the exception of CertificateRequests which are waiting on PR 2918 to be merged. Unfortunately there aren't other draft-19 implementations out there yet (that I know of) so there has been no inter-operability testing. Therefore I don't claim it to be bug free!! :-( As and when other implementations come along I will test it and fix anything we find. The immediate impact of this is that anyone using master for testing will find they are no longer able to negotiate TLSv1.3 with any implementations still using draft-18 (i.e. most/all of them). To enable people to still do that we have created a new branch "tlsv1.3-draft-18" in the repo which was done immediately before pulling in the draft-19 changes. I plan to maintain that branch with any required draft-18 interoperability fixes for a short time. Matt From tshort at akamai.com Thu Mar 16 15:16:33 2017 From: tshort at akamai.com (Short, Todd) Date: Thu, 16 Mar 2017 15:16:33 +0000 Subject: [openssl-dev] TLSv1.3 draft 19 support In-Reply-To: <7105c5dd-d70e-5e30-7b3d-1663ffbc2e2f@openssl.org> References: <7105c5dd-d70e-5e30-7b3d-1663ffbc2e2f@openssl.org> Message-ID: <2A6E5477-DB8E-423A-980B-000F79B74503@akamai.com> Thanks Matt! -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Mar 16, 2017, at 10:35 AM, Matt Caswell > wrote: All, I have just pushed to master the updates necessary for TLSv1.3 draft-19 support. This covers most of the required changes with the exception of CertificateRequests which are waiting on PR 2918 to be merged. Unfortunately there aren't other draft-19 implementations out there yet (that I know of) so there has been no inter-operability testing. Therefore I don't claim it to be bug free!! :-( As and when other implementations come along I will test it and fix anything we find. The immediate impact of this is that anyone using master for testing will find they are no longer able to negotiate TLSv1.3 with any implementations still using draft-18 (i.e. most/all of them). To enable people to still do that we have created a new branch "tlsv1.3-draft-18" in the repo which was done immediately before pulling in the draft-19 changes. I plan to maintain that branch with any required draft-18 interoperability fixes for a short time. Matt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Mar 16 16:29:11 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 16 Mar 2017 16:29:11 +0000 Subject: [openssl-dev] Tuesday's code health day Message-ID: <28be5ad631b34e4eb9b61c50f050fdc4@usma1ex-dag1mb1.msg.corp.akamai.com> Our most recent code health Tuesday was a success. Nearly a dozen people worked to achieved the following: - Our external contributors wrote completely new unit test for previously untested API's (stack, LHASH, and RSA_padding_add_PKCS1_PSS_mgf1) , and added a large external test suite (Python Cryptography). Rock on! - We rolled the BoringSSL tests forward to a new version and fixed several previously-failing tests - We improved testing support on VMS and for Strawberry Perl - The DTLS and SRP tests were ported to the new test framework - Test for output support of non-ASCII characters in certificate names - There were also code-health requests that addressed other areas such as eliminating warnings and dead code, and improving code clarity - those are also very welcome! We thank the community for their interest, support, and help in improving OpenSSL. We hope you'll join our next Code Health Tuesday, planned for March 28. Watch for details! -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz From matt at openssl.org Thu Mar 16 16:40:08 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 16 Mar 2017 16:40:08 +0000 Subject: [openssl-dev] Tuesday's code health day In-Reply-To: <28be5ad631b34e4eb9b61c50f050fdc4@usma1ex-dag1mb1.msg.corp.akamai.com> References: <28be5ad631b34e4eb9b61c50f050fdc4@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <9c19b79e-d7b9-ca35-7605-140242258647@openssl.org> On 16/03/17 16:29, Salz, Rich via openssl-dev wrote: > Our most recent code health Tuesday was a success. Nearly a dozen people worked to achieved the following: > > - Our external contributors wrote completely new unit test for previously untested API's (stack, LHASH, and RSA_padding_add_PKCS1_PSS_mgf1) , and added a large external test suite (Python Cryptography). Rock on! > - We rolled the BoringSSL tests forward to a new version and fixed several previously-failing tests "several" probably undersells that :-) Previously 1183 BoringSSL tests were explicitly disabled. Now only 247 are explicitly disabled, i.e. we fixed 936 tests! That's at the same time as adding new ones due to rolling the BoringSSL tests forward. Matt > - We improved testing support on VMS and for Strawberry Perl > - The DTLS and SRP tests were ported to the new test framework > - Test for output support of non-ASCII characters in certificate names > - There were also code-health requests that addressed other areas such as eliminating warnings and dead code, and improving code clarity - those are also very welcome! > > We thank the community for their interest, support, and help in improving OpenSSL. We hope you'll join our next Code Health Tuesday, planned for March 28. Watch for details! > > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz at jabber.at Twitter: RichSalz > > From lists at rustichelli.net Mon Mar 20 18:16:34 2017 From: lists at rustichelli.net (lists) Date: Mon, 20 Mar 2017 19:16:34 +0100 Subject: [openssl-dev] how to implement functions for STACK OF custom type? Message-ID: <92433394-0c1a-e502-8f44-7d500a0ed3f0@rustichelli.net> Hi all, I likely have a trivial question... I am exploring my options with OpenSSL and specifically I am trying to manage the stacks for some custom objects. Currently, I have this code (sort of): typedef struct myThingA_st { ASN1_OBJECT aID; ASN1_OCTET_STRING aOCST; } myThingA; DECLARE_ASN1_ITEM(myThingA) DECLARE_ASN1_FUNCTIONS(myThingA) DECLARE_STACK_OF(myThingA) // the next one seems to be ininfluent for my purpose, is it? DECLARE_ASN1_SET_OF(myThingA) typedef struct myThingB_st { // SEQUENCE OF { ... } STACK_OF(myThingA) myThingA_sk; } myThingB; // DECLARE_ASN1_ITEM(myThingB) DECLARE_STACK_OF(myThingB) // DECLARE_ASN1_FUNCTIONS(myThingB) // the next one seems to be ininfluent for my purpose, is it? DECLARE_ASN1_SET_OF(myThingB) I thought that the basic functions for the stacks to be available (such as sk_myThingA_new, sk_myThingA_push...), yet by compiling a main, for the first one that I tried to use I get: undefined reference to `sk_myThingA_value' so I likely have to activate some macro in the C code, like IMPLEMENT_STACK_STUFF(myThingA) IMPLEMENT_STACK_STUFF(myThingB) right? If so, what would it be? Or is it o me to write the functions down? From jason.vas.dias at gmail.com Mon Mar 20 22:41:12 2017 From: jason.vas.dias at gmail.com (Jason Vas Dias) Date: Mon, 20 Mar 2017 22:41:12 +0000 Subject: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release Message-ID: Hi - much thanks for many years of great OpenSSL releases, but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k release on the website as the 'latest / best OpenSSL release' - this just wastes everybody's time . No using software can use this release, such as the latest releases of OpenSSH, ISC BIND (named) / ISC DHCP, ntpd (... the list can go on and on - does the latest httpd compile with it? ) without major restructuring . I did waste a few hours today getting ISC BIND 9.11.0-P3 & DHCP 4.3.5 & ntpd 4.3.93 to use 1.1.0e , (I can generate & send the patches for them to anyone who wants them), and wpa_supplicant v2.7 , and got the latest version of OpenSSH (v7.4.P1) to at least compile with it, but that version of OpenSSH is broken in so many ways because of openssl 1.1.0 - it can't even read or write its ED25519 /etc/ssh_host_ed25519.key file. It looks like too much work to support the new 1.1.0 API across all current OpenSSL using applications - and what do these API "improvements" really get us? At least ISC BIND & dhclient & wpa_supplican do now work with it - these are the programs I depend on for my internet connection - but I haven't really rested their OpenSSL using features much . And then I saw the list of vulnerabilities which apply only to the 1.1.0 branch and I realized "Oh, this is a development branch" . Now tonight / tomorrow I'll be recompiling OpenSSH, BIND, DHCP & wpa_supplicant to use 1.0.2k & undoing all the patches I made (which mainly involved including the '*_lo?cl.h' & '*_int.h' headers where the API they were using moved, which are now not installed in /usr/include/openssl ). Why you are now hiding the API used by 90% of OpenSSL's core users I do not understand. Couldn't you please inform users of this on the main openssl.org web-page ? I appreciate the 1.1.0 software does pass its test suite, and may introduce some API "improvements", if the old OpenSSL API did not have such a vast legacy of users to support - I question how any API "improvement" can outweigh the cost of restructuring all current using code to use it, especially with such a complex and typically mission critical library such as OpenSSL. Sorry, I just had to let you have my two cents worth here. Thanks & Regards, Jason. From kurt at roeckx.be Mon Mar 20 23:18:58 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 21 Mar 2017 00:18:58 +0100 Subject: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release In-Reply-To: References: Message-ID: <20170320231857.pkanemkvx4njejno@roeckx.be> On Mon, Mar 20, 2017 at 10:41:12PM +0000, Jason Vas Dias wrote: > Hi - much thanks for many years of great OpenSSL releases, > but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k > release on the website as the 'latest / best OpenSSL release' - this just > wastes everybody's time . No using software can use this release, > such as the latest releases of OpenSSH, ISC BIND (named) / ISC DHCP, ntpd > (... the list can go on and on - does the latest httpd compile with it? ) I have send patches for all of those that you just mentioned so that they can get build using both 1.0.2 and 1.1.0. > I did waste a few hours today getting ISC BIND 9.11.0-P3 & DHCP 4.3.5 > & ntpd 4.3.93 to use 1.1.0e , (I can generate & send the patches for > them to anyone who wants them), DHCP 4.3.5 seems to work just fine with 1.1.0. The latest ntp release is 4.2.8p9 which should just work with openssl 1.1.0. (I have no idea why they don't list it on their download page now, or why the development version is so old.) bind has applied patches, I'm just not sure in which branches. > the latest version of OpenSSH (v7.4.P1) to at least compile with it, > but that version of OpenSSH is broken in so many ways because of > openssl 1.1.0 - it can't even read or write its ED25519 > /etc/ssh_host_ed25519.key file. The ed25519 support in openssh doesn't even come from openssl. > which mainly > involved including the '*_lo?cl.h' & '*_int.h' headers Including the internal headers is not a good patch. This will break. Kurt From jason.vas.dias at gmail.com Tue Mar 21 00:13:57 2017 From: jason.vas.dias at gmail.com (Jason Vas Dias) Date: Tue, 21 Mar 2017 00:13:57 +0000 Subject: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release In-Reply-To: <20170320231857.pkanemkvx4njejno@roeckx.be> References: <20170320231857.pkanemkvx4njejno@roeckx.be> Message-ID: On 20/03/2017, Kurt Roeckx wrote: > On Mon, Mar 20, 2017 at 10:41:12PM +0000, Jason Vas Dias wrote: >> Hi - much thanks for many years of great OpenSSL releases, >> but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k >> release on the website as the 'latest / best OpenSSL release' - this just >> wastes everybody's time . No using software can use this release, >> such as the latest releases of OpenSSH, ISC BIND (named) / ISC DHCP, >> ntpd >> (... the list can go on and on - does the latest httpd compile with it? >> ) > > I have send patches for all of those that you just mentioned so > that they can get build using both 1.0.2 and 1.1.0. Great, thanks, but they are not being distributed anywhere . Please could you send the patch sets against bind-9.11.0-P3 & DHCP 9.3.5 to me ? > >> I did waste a few hours today getting ISC BIND 9.11.0-P3 & DHCP 4.3.5 >> & ntpd 4.3.93 to use 1.1.0e , (I can generate & send the patches for >> them to anyone who wants them), > > DHCP 4.3.5 seems to work just fine with 1.1.0. > Yes, as I said, named & dhcp & wpa_supplicant are working fine with 1.1.0 and after patching to use the internal 1.1.0 headers. DHCP uses OpenSSL via the BIND libisc & libdns libraries, anyway , so doesn't really count as an OpenSSL user in its own right. None of their latest versions can compile unmodified against 1.1.0 . That is why I think it is somewhat premature to call 1.1.0 the official stable OpenSSL release. > The latest ntp release is 4.2.8p9 which should just work with > openssl 1.1.0. (I have no idea why they don't list it on their > download page now, or why the development version is so old.) > No, the latest version is 4.3.93 , not 4.2.8p9, and it also needed to include ^ ^ internal 1.1.0 headers to compile. > bind has applied patches, I'm just not sure in which branches. > It may be years yet before they see the light of day in a BIND release. >> the latest version of OpenSSH (v7.4.P1) to at least compile with it, >> but that version of OpenSSH is broken in so many ways because of >> openssl 1.1.0 - it can't even read or write its ED25519 >> /etc/ssh_host_ed25519.key file. > > The ed25519 support in openssh doesn't even come from openssl. > What happens is OpenSSH's cipher.c calls if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv, (do_encrypt == CIPHER_ENCRYPT)) == 0) { ret = SSH_ERR_LIBCRYPTO_ERROR; goto out; } which always does 'goto out' for any ED25519 file. OpenSSL's EVP_CipherInit calls EVP_CipherInit_ex which fails in this case. I'm not really an OpenSSL / cryptography expert (but have written a few SSL / plain transparent I/O modules in C/C++ in my time), but I can see OpenSSH is expecting OpenSSL to respond in a certain way to these parameters which it does not do in 1.1.0, but does in 1.0.2x . >> which mainly >> involved including the '*_lo?cl.h' & '*_int.h' headers > > Including the internal headers is not a good patch. This will > break. > It doesn't break at all - the code remains 100% unchanged - just different headers need including - and seems to work fine including the API hiding headers. But considering the work necessary to make all OpenSSH using apps include those headers , it doesn't seem worth it. My question is really, why ? Why make ALL OpenSSL users (and there are thousands of them) now jump through new hoops to use the same API they've been using for years ? What does it get them? And my point is really not to criticize your effort, it is just a plea to make clear on the web-page that the 1.1.0 branch is a development branch and does not work yet with most OpenSSL using applications . OpenSSL in its 1.0.2 incarnation has been hardened by over (10,15,20)? years of testing , and its API is usable by all OpenSSL using applications, unlike 1.1.0 . Out of these using applications, which have their latest versions switched to using the 1.1.0 API : bind, OpenSSH, httpd, firefox ? AFAICS, none. It is just premature and confusing and a timewaster to claim the latest stable OpenSSL release is 1.1.0 on the main web page. No using applications can use it yet. Give them a few years, and they will . But please, make clear on the web-page that most applications still use the 1.0.2 API . Friendly Regards, Jason From darshanmody at avaya.com Tue Mar 21 07:24:44 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Tue, 21 Mar 2017 07:24:44 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A10615A@AZ-FFEXMB03.global.avaya.com> Hi, Can anyone in the developer forum clarify whether there is an issue here? Thanks Darshan From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Mody, Darshan (Darshan) Sent: Wednesday, March 15, 2017 11:15 AM To: openssl-dev at openssl.org Cc: Bahr, William G (Bill); Vaquero, Alejandro (Alejandro) Subject: [openssl-dev] Memory leak in application when we use ECDH Hi, We have observed memory leak when we register for ECDH callback(SSL_set_tmp_ecdh_callback). While performing negative testing with load we find that the applications starts leaking memory. Further checking the Openssl implementation in the s3_srvr.c file (openssl version 1.0.2). I find that a pointer is not deleted after copying EC_KEY from the application or EC_KEY_new being called. I suspect the below code. if (type & SSL_kEECDH) { const EC_GROUP *group; ecdhp = cert->ecdh_tmp; if (s->cert->ecdh_tmp_auto) { /* Get NID of appropriate shared curve */ int nid = tls1_shared_curve(s, -2); if (nid != NID_undef) ecdhp = EC_KEY_new_by_curve_name(nid); <-- Even memory allocated in this case is not de-allocated. } else if ((ecdhp == NULL) && s->cert->ecdh_tmp_cb) { ecdhp = s->cert->ecdh_tmp_cb(s, <-- Application is responsible for the EC_KEY and its memory SSL_C_IS_EXPORT(s->s3-> tmp.new_cipher), SSL_C_EXPORT_PKEYLENGTH(s-> s3->tmp.new_cipher)); } if (ecdhp == NULL) { al = SSL_AD_HANDSHAKE_FAILURE; SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, SSL_R_MISSING_TMP_ECDH_KEY); goto f_err; } if (s->s3->tmp.ecdh != NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_INTERNAL_ERROR); goto err; } /* Duplicate the ECDH structure. */ if (ecdhp == NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } if (s->cert->ecdh_tmp_auto) ecdh = ecdhp; else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { <-- Once the key is duplicated the memory for the application should be released? SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } s->s3->tmp.ecdh = ecdh; if ((EC_KEY_get0_public_key(ecdh) == NULL) || (EC_KEY_get0_private_key(ecdh) == NULL) || (s->options & SSL_OP_SINGLE_ECDH_USE)) { if (!EC_KEY_generate_key(ecdh)) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } } if (((group = EC_KEY_get0_group(ecdh)) == NULL) || (EC_KEY_get0_public_key(ecdh) == NULL) || (EC_KEY_get0_private_key(ecdh) == NULL)) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } if (SSL_C_IS_EXPORT(s->s3->tmp.new_cipher) && (EC_GROUP_get_degree(group) > 163)) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, SSL_R_ECGROUP_TOO_LARGE_FOR_CIPHER); goto err; } /* * XXX: For now, we only support ephemeral ECDH keys over named * (not generic) curves. For supported named curves, curve_id is * non-zero. */ if ((curve_id = tls1_ec_nid2curve_id(EC_GROUP_get_curve_name(group))) == 0) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, SSL_R_UNSUPPORTED_ELLIPTIC_CURVE); goto err; } /* * Encode the public key. First check the size of encoding and * allocate memory accordingly. */ encodedlen = EC_POINT_point2oct(group, EC_KEY_get0_public_key(ecdh), POINT_CONVERSION_UNCOMPRESSED, NULL, 0, NULL); encodedPoint = (unsigned char *) OPENSSL_malloc(encodedlen * sizeof(unsigned char)); bn_ctx = BN_CTX_new(); if ((encodedPoint == NULL) || (bn_ctx == NULL)) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_MALLOC_FAILURE); goto err; } encodedlen = EC_POINT_point2oct(group, EC_KEY_get0_public_key(ecdh), POINT_CONVERSION_UNCOMPRESSED, encodedPoint, encodedlen, bn_ctx); if (encodedlen == 0) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } BN_CTX_free(bn_ctx); bn_ctx = NULL; /* * XXX: For now, we only support named (not generic) curves in * ECDH ephemeral key exchanges. In this situation, we need four * additional bytes to encode the entire ServerECDHParams * structure. */ n = 4 + encodedlen; /* * We'll generate the serverKeyExchange message explicitly so we * can set these to NULLs */ r[0] = NULL; r[1] = NULL; r[2] = NULL; r[3] = NULL; } else Thanks for your help in advance Regards Darshan -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Mar 21 08:55:30 2017 From: levitte at openssl.org (Richard Levitte) Date: Tue, 21 Mar 2017 09:55:30 +0100 (CET) Subject: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release In-Reply-To: References: <20170320231857.pkanemkvx4njejno@roeckx.be> Message-ID: <20170321.095530.1393856938137029690.levitte@openssl.org> In message on Tue, 21 Mar 2017 00:13:57 +0000, Jason Vas Dias said: jason.vas.dias> On 20/03/2017, Kurt Roeckx wrote: jason.vas.dias> > The ed25519 support in openssh doesn't even come from openssl. jason.vas.dias> > jason.vas.dias> What happens is OpenSSH's cipher.c calls jason.vas.dias> if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv, jason.vas.dias> (do_encrypt == CIPHER_ENCRYPT)) == 0) { jason.vas.dias> ret = SSH_ERR_LIBCRYPTO_ERROR; jason.vas.dias> goto out; jason.vas.dias> } jason.vas.dias> which always does 'goto out' for any ED25519 file. That would happen if ssh_host_ed25519_key is password protected and the cipher used to encrypt the key isn't recognised in OpenSSL 1.1.0 (and considering the current master of openssh-portable doesn't build cleanly against OpenSSL 1.1.0e and I therefore suppose you've hacked around, I can't even begin to say where the fault came in). It also depends on your OpenSSL configuration, since you can disable most algorithms it carries... jason.vas.dias> >> which mainly jason.vas.dias> >> involved including the '*_lo?cl.h' & '*_int.h' headers jason.vas.dias> > jason.vas.dias> > Including the internal headers is not a good patch. This will jason.vas.dias> > break. jason.vas.dias> > jason.vas.dias> jason.vas.dias> It doesn't break at all - the code remains 100% unchanged - just different jason.vas.dias> headers need including - and seems to work fine including the API jason.vas.dias> hiding headers. The structures you find in there are made private for a reason, we need the liberty to make changes in them in future developments without disturbing the ABI (not just the API). So some time in the future, it will break. jason.vas.dias> And my point is really not to criticize your effort, it is just a plea to make jason.vas.dias> clear on the web-page that the 1.1.0 branch is a development branch and jason.vas.dias> does not work yet with most OpenSSL using applications . It isn't a development branch. We see it as a stable release, i.e. no further development apart from bug fixes. "master" is the development branch. jason.vas.dias> OpenSSL in its 1.0.2 incarnation has been hardened by over (10,15,20)? years jason.vas.dias> of testing , and its API is usable by all OpenSSL using applications, jason.vas.dias> unlike 1.1.0 . Jyst to put things in perspective, OpenSSL 1.0.0 was released 2010-Mar-29. That was the start of the 1.0.x series. OpenSSL 1.0.2 was released 2015-Jan-22. OpenSSL 1.1.0 marks the start of the 1.1.x series, which isn't source compatible with the 1.0.x series. We have talked about this in different ways even before the first Alpha release was made (over a year ago). Either way, the 1.0.2 branch is supported until the end of 2019. One could say that's how long other application authors have to rework their source, although that's not really true since anyone can keep the 1.0.2 source around as long as they want (hey, even we do). Maybe you expected all applications to have converted the moment we declared our 1.1.0 release stable? That will not happen... as far as we've observed, most are hardly even looking before we've made a stable release (which I agree is unfortunate). Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From pwalten at au1.ibm.com Tue Mar 21 09:41:00 2017 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Tue, 21 Mar 2017 09:41:00 +0000 Subject: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release In-Reply-To: <20170321.095530.1393856938137029690.levitte@openssl.org> References: <20170321.095530.1393856938137029690.levitte@openssl.org>, <20170320231857.pkanemkvx4njejno@roeckx.be> Message-ID: An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Mar 21 09:46:31 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Mar 2017 09:46:31 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> Message-ID: On 15/03/17 05:44, Mody, Darshan (Darshan) wrote: > Hi, > > We have observed memory leak when we register for ECDH > callback(SSL_set_tmp_ecdh_callback). While performing negative testing > with load we find that the applications starts leaking memory. > > Further checking the Openssl implementation in the s3_srvr.c file > (openssl version 1.0.2). I find that a pointer is not deleted after > copying EC_KEY from the application or EC_KEY_new being called. > > I suspect the below code. The code looks ok to me: if (s->cert->ecdh_tmp_auto) ecdh = ecdhp; else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } s->s3->tmp.ecdh = ecdh; After the EC_KEY_dup() call, the result is immediately assigned to "s->s3->tmp.ecdh". This will get freed when you call SSL_free(). Similarly in the non-callback case. There is a potential leak in this case: if (s->s3->tmp.ecdh != NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_INTERNAL_ERROR); goto err; } But this is a "should not happen" scenario - so there is another bug if that is happening - and you would see "internal error" messages on the error stack. Another slight oddity in this code is the double check of ecdhp against NULL which seems redundant (but otherwise harmless): if (ecdhp == NULL) { al = SSL_AD_HANDSHAKE_FAILURE; SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, SSL_R_MISSING_TMP_ECDH_KEY); goto f_err; } ... /* Duplicate the ECDH structure. */ if (ecdhp == NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } Also note that SSL_set_tmp_ecdh_callback() has been removed from OpenSSL 1.1.0 with this commit description: commit 6f78b9e824c053d062188578635c575017b587c5 Author: Kurt Roeckx AuthorDate: Fri Dec 4 22:22:31 2015 +0100 Commit: Kurt Roeckx CommitDate: Fri Dec 4 22:22:31 2015 +0100 Remove support for SSL_{CTX_}set_tmp_ecdh_callback(). This only gets used to set a specific curve without actually checking that the peer supports it or not and can therefor result in handshake failures that can be avoided by selecting a different cipher. Reviewed-by: Dr. Stephen Henson Matt From matt at openssl.org Tue Mar 21 09:58:16 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Mar 2017 09:58:16 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> Message-ID: <225a39ec-4d21-9193-a869-053707a0e5df@openssl.org> On 21/03/17 09:46, Matt Caswell wrote: > > There is a potential leak in this case: > > if (s->s3->tmp.ecdh != NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, > ERR_R_INTERNAL_ERROR); > goto err; > } > > But this is a "should not happen" scenario - so there is another bug if > that is happening - and you would see "internal error" messages on the > error stack. > > Another slight oddity in this code is the double check of ecdhp against > NULL which seems redundant (but otherwise harmless): > > if (ecdhp == NULL) { > al = SSL_AD_HANDSHAKE_FAILURE; > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, > SSL_R_MISSING_TMP_ECDH_KEY); > goto f_err; > } > > ... > > /* Duplicate the ECDH structure. */ > if (ecdhp == NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); > goto err; > } Fix for the above issues (which is unlikely to solve your problem) is here: https://github.com/openssl/openssl/pull/3003 Matt From raja.ashok at huawei.com Tue Mar 21 15:24:57 2017 From: raja.ashok at huawei.com (Raja ashok) Date: Tue, 21 Mar 2017 15:24:57 +0000 Subject: [openssl-dev] DTLS is not sending alert in case of BAD CCS Message-ID: Hi All, Looks like there is a typo mistake in dtls1_read_bytes, because of this alert is not send for bad CCS. In dtls1_read_bytes, incase of bad change cipher spec we are setting alert code (SSL_AD_ILLEGAL_PARAMETER) to variable ?i? and doing ?goto err?. I feel we are trying to send alert in this case, so we need to set the alert in ?al? and do ?goto f_err?. In case of TLS we are sending alert. Note : I am referring 1.0.2.k version of OpenSSL Regards, Ashok ________________________________ [Company_logo] Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ________________________________ ???????????????????????????????????????? ???????????????????????????????????????? ??????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6737 bytes Desc: image001.jpg URL: From matt at openssl.org Tue Mar 21 16:19:54 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Mar 2017 16:19:54 +0000 Subject: [openssl-dev] DTLS is not sending alert in case of BAD CCS In-Reply-To: References: Message-ID: <5498fd0e-1170-89c4-053b-8dc318c5d38b@openssl.org> https://github.com/openssl/openssl/pull/3009 On 21/03/17 15:24, Raja ashok wrote: > Hi All, > > > > Looks like there is a typo mistake in dtls1_read_bytes, because of this > alert is not send for bad CCS. > > > > In dtls1_read_bytes, incase of bad change cipher spec we are setting > alert code (SSL_AD_ILLEGAL_PARAMETER) to variable ?i? and doing ?goto > err?. I feel we are trying to send alert in this case, so we need to set > the alert in ?al? and do ?goto f_err?. > > > > In case of TLS we are sending alert. > > > > Note : I am referring 1.0.2.k version of OpenSSL > > > > Regards, > > Ashok > > > > ------------------------------------------------------------------------ > > Company_logo > > Raja Ashok V K > Huawei Technologies > Bangalore, India > http://www.huawei.com > > ------------------------------------------------------------------------ > > ???????????????????????????????????? > ???? > ???????????????????????????????????? > ???? > ??????????????????????????????????? > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > > > > From Richard.Koenning at ts.fujitsu.com Tue Mar 21 17:45:42 2017 From: Richard.Koenning at ts.fujitsu.com (=?ISO-8859-1?Q?Richard_K=F6nning?=) Date: Tue, 21 Mar 2017 18:45:42 +0100 Subject: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release In-Reply-To: References: <20170320231857.pkanemkvx4njejno@roeckx.be> Message-ID: <58D166C6.6030705@ts.fujitsu.com> On 21.03.2017 01:13, Jason Vas Dias wrote: > On 20/03/2017, Kurt Roeckx wrote: >> The latest ntp release is 4.2.8p9 which should just work with >> openssl 1.1.0. (I have no idea why they don't list it on their >> download page now, or why the development version is so old.) >> > > No, the latest version is 4.3.93 , not 4.2.8p9, and it also needed to include > ^ ^ > internal 1.1.0 headers to compile. The latest stable NTP version is 4.2.8p9 (see e.g. http://support.ntp.org/rss/releases.xml), the latest development version is 4.3.93 and is a half year older than 4.2.8p9. Ciao, Richard From jason.vas.dias at gmail.com Tue Mar 21 18:16:49 2017 From: jason.vas.dias at gmail.com (Jason Vas Dias) Date: Tue, 21 Mar 2017 18:16:49 +0000 Subject: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release In-Reply-To: <20170321.095530.1393856938137029690.levitte@openssl.org> References: <20170320231857.pkanemkvx4njejno@roeckx.be> <20170321.095530.1393856938137029690.levitte@openssl.org> Message-ID: Thanks for your informative replies! I hope BIND, OpenSSH et al start using the 1.1.0 API soon. RE: jason.vas.dias> On 20/03/2017, Kurt Roeckx wrote: jason.vas.dias> > The ed25519 support in openssh doesn't even come from openssl. jason.vas.dias> > jason.vas.dias> What happens is OpenSSH's cipher.c calls jason.vas.dias> if (EVP_CipherInit(cc->evp, type, NULL, (u_char *)iv, jason.vas.dias> (do_encrypt == CIPHER_ENCRYPT)) == 0) { jason.vas.dias> ret = SSH_ERR_LIBCRYPTO_ERROR; jason.vas.dias> goto out; jason.vas.dias> } jason.vas.dias> which always does 'goto out' for any ED25519 file. That would happen if ssh_host_ed25519_key is password protected and the cipher used to encrypt the key isn't recognised in OpenSSL 1.1.0 (and considering the current master of openssh-portable doesn't build cleanly against OpenSSL 1.1.0e and I therefore suppose you've hacked around, I can't even begin to say where the fault came in). It also depends on your OpenSSL configuration, since you can disable most algorithms it carries... But none of my host keys were password protected. They were just what resulted from the command: $ ssh-keygen -A which is run on initial openssh installation. The modifications I made were trivial : o Including the hidden API headers , o initializing automatic SSL structs - ie '{struct}_CTX v ={0};' , not '{struct}_CTX v;' ( else the {struct}_init(&v) function ( I think evp_init() ) could try free()-ing garbage pointer members ( in named ) ) o changing some structure member references from s->m to s.m - these were verified by compiler. That really is the extent of all mods I made to openssh / BIND . Openssh was then unable to read or write the existing /etc/ssh_host_ed25519_key file ( not PW protected ), so NO ssh app can run, and 'ssh_keygen -A' failed to write a new ed25519 key file (not pw protected) when I moved all the old files out of the way , failing ( under gdb ) at that point in the cipher_init() code I posted before . If anyone has managed to get openssh working under OpenSSL 1.1.0 please let me know & I'll try upgrading again. But until 1.1.0 adoption becomes more widespread, I still think it would be helpful if the main openssl.org webpage let users know this is the case , with a statement such as 'most openssl using applications have not upgraded to 1.1.0 yet' . This would prevent others from wasting time as I was led to do. Regards, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From darshanmody at avaya.com Thu Mar 23 04:35:57 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Thu, 23 Mar 2017 04:35:57 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <225a39ec-4d21-9193-a869-053707a0e5df@openssl.org> References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> <225a39ec-4d21-9193-a869-053707a0e5df@openssl.org> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A10749A@AZ-FFEXMB03.global.avaya.com> Matt, But openssl does not release the memory when it has duplicated the EC Key which comes from the application /* Duplicate the ECDH structure. */ if (ecdhp == NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } if (s->cert->ecdh_tmp_auto) ecdh = ecdhp; else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } Thanks Darshan -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Tuesday, March 21, 2017 3:28 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH On 21/03/17 09:46, Matt Caswell wrote: > > There is a potential leak in this case: > > if (s->s3->tmp.ecdh != NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, > ERR_R_INTERNAL_ERROR); > goto err; > } > > But this is a "should not happen" scenario - so there is another bug > if that is happening - and you would see "internal error" messages on > the error stack. > > Another slight oddity in this code is the double check of ecdhp > against NULL which seems redundant (but otherwise harmless): > > if (ecdhp == NULL) { > al = SSL_AD_HANDSHAKE_FAILURE; > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, > SSL_R_MISSING_TMP_ECDH_KEY); > goto f_err; > } > > ... > > /* Duplicate the ECDH structure. */ > if (ecdhp == NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); > goto err; > } Fix for the above issues (which is unlikely to solve your problem) is here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no&e= Matt -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs&e= From darshanmody at avaya.com Thu Mar 23 07:05:16 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Thu, 23 Mar 2017 07:05:16 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A10749A@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> <225a39ec-4d21-9193-a869-053707a0e5df@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10749A@AZ-FFEXMB03.global.avaya.com> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A107546@AZ-FFEXMB03.global.avaya.com> 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 (s->cert->ecdh_tmp_auto) ecdh = ecdhp; else { if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } else { /* Release memory from cb */ If (NULL !=ecdhp) { EC_KEY_free(ecdhp); } } } Thanks Darshan -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Mody, Darshan (Darshan) Sent: Thursday, March 23, 2017 10:06 AM To: openssl-dev at openssl.org Cc: Bahr, William G (Bill) Subject: Re: [openssl-dev] Memory leak in application when we use ECDH Matt, But openssl does not release the memory when it has duplicated the EC Key which comes from the application /* Duplicate the ECDH structure. */ if (ecdhp == NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } if (s->cert->ecdh_tmp_auto) ecdh = ecdhp; else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); goto err; } Thanks Darshan -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Tuesday, March 21, 2017 3:28 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH On 21/03/17 09:46, Matt Caswell wrote: > > There is a potential leak in this case: > > if (s->s3->tmp.ecdh != NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, > ERR_R_INTERNAL_ERROR); > goto err; > } > > But this is a "should not happen" scenario - so there is another bug > if that is happening - and you would see "internal error" messages on > the error stack. > > Another slight oddity in this code is the double check of ecdhp > against NULL which seems redundant (but otherwise harmless): > > if (ecdhp == NULL) { > al = SSL_AD_HANDSHAKE_FAILURE; > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, > SSL_R_MISSING_TMP_ECDH_KEY); > goto f_err; > } > > ... > > /* Duplicate the ECDH structure. */ > if (ecdhp == NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); > goto err; > } Fix for the above issues (which is unlikely to solve your problem) is here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no&e= Matt -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs&e= -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=ItYO5obXpUhcVAqtr-HAnmatrYOEJ-EpjZhn-eCTsyg&s=EYfD8Wpi4Eji8E2PwNF9obPY-g4EXP5FXF1AzbJtMGU&e= From matt at openssl.org Thu Mar 23 10:00:45 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Mar 2017 10:00:45 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A10749A@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> <225a39ec-4d21-9193-a869-053707a0e5df@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10749A@AZ-FFEXMB03.global.avaya.com> Message-ID: 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 there is no "official" description of the memory management semantics of this function (and like I said it has been removed from later versions of OpenSSL altogether so it is unlikely to ever get documented). However my interpretation of the way the code is written is that this is a deliberate design choice, i.e. it is deliberately left to the the application to mange this memory. Presumably multiple invocations across multiple connections could return the same value so it would be inappropriate for OpenSSL to free it. Matt > > /* Duplicate the ECDH structure. */ > if (ecdhp == NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); > goto err; > } > if (s->cert->ecdh_tmp_auto) > ecdh = ecdhp; > else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); > goto err; > } > > Thanks > Darshan > > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell > Sent: Tuesday, March 21, 2017 3:28 PM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH > > > > On 21/03/17 09:46, Matt Caswell wrote: >> >> There is a potential leak in this case: >> >> if (s->s3->tmp.ecdh != NULL) { >> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, >> ERR_R_INTERNAL_ERROR); >> goto err; >> } >> >> But this is a "should not happen" scenario - so there is another bug >> if that is happening - and you would see "internal error" messages on >> the error stack. >> >> Another slight oddity in this code is the double check of ecdhp >> against NULL which seems redundant (but otherwise harmless): >> >> if (ecdhp == NULL) { >> al = SSL_AD_HANDSHAKE_FAILURE; >> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, >> SSL_R_MISSING_TMP_ECDH_KEY); >> goto f_err; >> } >> >> ... >> >> /* Duplicate the ECDH structure. */ >> if (ecdhp == NULL) { >> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); >> goto err; >> } > > Fix for the above issues (which is unlikely to solve your problem) is here: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3003&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no&e= > > Matt > > -- > openssl-dev mailing list > To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuki2qv8&s=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs&e= > From darshanmody at avaya.com Thu Mar 23 10:13:13 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Thu, 23 Mar 2017 10:13:13 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> <225a39ec-4d21-9193-a869-053707a0e5df@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10749A@AZ-FFEXMB03.global.avaya.com> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A107638@AZ-FFEXMB03.global.avaya.com> 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. Thanks Darshan -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Thursday, March 23, 2017 3:31 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH 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 there is no "official" description of the memory management semantics of this function (and like I said it has been removed from later versions of OpenSSL altogether so it is unlikely to ever get documented). However my interpretation of the way the code is written is that this is a deliberate design choice, i.e. it is deliberately left to the the application to mange this memory. Presumably multiple invocations across multiple connections could return the same value so it would be inappropriate for OpenSSL to free it. Matt > > /* Duplicate the ECDH structure. */ > if (ecdhp == NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); > goto err; > } > if (s->cert->ecdh_tmp_auto) > ecdh = ecdhp; > else if ((ecdh = EC_KEY_dup(ecdhp)) == NULL) { > SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); > goto err; > } > > Thanks > Darshan > > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf > Of Matt Caswell > Sent: Tuesday, March 21, 2017 3:28 PM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH > > > > On 21/03/17 09:46, Matt Caswell wrote: >> >> There is a potential leak in this case: >> >> if (s->s3->tmp.ecdh != NULL) { >> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, >> ERR_R_INTERNAL_ERROR); >> goto err; >> } >> >> But this is a "should not happen" scenario - so there is another bug >> if that is happening - and you would see "internal error" messages on >> the error stack. >> >> Another slight oddity in this code is the double check of ecdhp >> against NULL which seems redundant (but otherwise harmless): >> >> if (ecdhp == NULL) { >> al = SSL_AD_HANDSHAKE_FAILURE; >> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, >> SSL_R_MISSING_TMP_ECDH_KEY); >> goto f_err; >> } >> >> ... >> >> /* Duplicate the ECDH structure. */ >> if (ecdhp == NULL) { >> SSLerr(SSL_F_SSL3_SEND_SERVER_KEY_EXCHANGE, ERR_R_ECDH_LIB); >> goto err; >> } > > Fix for the above issues (which is unlikely to solve your problem) is here: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openss > l_openssl_pull_3003&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7I > nzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi-yB56pEUuk > i2qv8&s=pgqizfrjno8szLWBm_ROxbSePFpUYCO4KboURycC0no&e= > > Matt > > -- > openssl-dev mailing list > To unsubscribe: > https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_m > ailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEU > LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=lmOlT993M2YueHJqZT9cKMDBkwGi > -yB56pEUuki2qv8&s=jaW-ScgHUXwPTGLNdnt6AsNePpsg5n1Inju4e0V6SAs&e= > -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=jvDI18EtBUGVhF0dlpzP1E0w75ZPjyBprI47vr1-QlA&s=QwfWOZbsFqgCiO23c3Z6HmnkCgfsT94LaHQSoaQLIFM&e= From matt at openssl.org Thu Mar 23 10:39:02 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Mar 2017 10:39:02 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A107638@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> <225a39ec-4d21-9193-a869-053707a0e5df@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10749A@AZ-FFEXMB03.global.avaya.com> <25D2EC755404B4409F263AC6D050FEBB2A107638@AZ-FFEXMB03.global.avaya.com> Message-ID: 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 certificates. I > cannot pin point the code in openssl with this regard. Are you able to create a simple reproducer demonstrating the problem with the callback? Matt From darshanmody at avaya.com Thu Mar 23 13:19:35 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Thu, 23 Mar 2017 13:19:35 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> <225a39ec-4d21-9193-a869-053707a0e5df@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10749A@AZ-FFEXMB03.global.avaya.com> <25D2EC755404B4409F263AC6D050FEBB2A107638@AZ-FFEXMB03.global.avaya.com> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A1077F2@AZ-FFEXMB03.global.avaya.com> 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 to connect to server using invalid certificates and in course of time the memory was increasing). Thanks Darshan -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Thursday, March 23, 2017 4:09 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH 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 certificates. I > cannot pin point the code in openssl with this regard. Are you able to create a simple reproducer demonstrating the problem with the callback? Matt -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=bLfMhjtc7o6YlbbKPhSGSKPuhTJsYubiC_LV17YO3do&s=CIdcV48IKxBzbTWaEpB4zcKDD76FwUj3wuMFrxa50UY&e= From matt at openssl.org Thu Mar 23 13:25:01 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Mar 2017 13:25:01 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A1077F2@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> <225a39ec-4d21-9193-a869-053707a0e5df@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10749A@AZ-FFEXMB03.global.avaya.com> <25D2EC755404B4409F263AC6D050FEBB2A107638@AZ-FFEXMB03.global.avaya.com> <25D2EC755404B4409F263AC6D050FEBB2A1077F2@AZ-FFEXMB03.global.avaya.com> Message-ID: <3fab20f8-b60c-6edc-7922-e184000c987c@openssl.org> 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 server. > > This was done with load (multiple while 1 script trying to connect to > server using invalid certificates and in course of time the memory > was increasing). Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. Matt > > Thanks Darshan > > -----Original Message----- From: openssl-dev > [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell > Sent: Thursday, March 23, 2017 4:09 PM To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] Memory leak in application when we use > ECDH > > > > 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 certificates. >> I cannot pin point the code in openssl with this regard. > > Are you able to create a simple reproducer demonstrating the problem > with the callback? > > Matt > From darshanmody at avaya.com Thu Mar 23 13:47:10 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Thu, 23 Mar 2017 13:47:10 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <3fab20f8-b60c-6edc-7922-e184000c987c@openssl.org> References: <25D2EC755404B4409F263AC6D050FEBB2A103782@AZ-FFEXMB03.global.avaya.com> <225a39ec-4d21-9193-a869-053707a0e5df@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10749A@AZ-FFEXMB03.global.avaya.com> <25D2EC755404B4409F263AC6D050FEBB2A107638@AZ-FFEXMB03.global.avaya.com> <25D2EC755404B4409F263AC6D050FEBB2A1077F2@AZ-FFEXMB03.global.avaya.com> <3fab20f8-b60c-6edc-7922-e184000c987c@openssl.org> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A10781E@AZ-FFEXMB03.global.avaya.com> 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 trust. 4. The connections from client to server fails In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved. Hope this helps Thanks Darshan -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Thursday, March 23, 2017 6:55 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH 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 server. > > This was done with load (multiple while 1 script trying to connect to > server using invalid certificates and in course of time the memory was > increasing). Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. Matt > > Thanks Darshan > > -----Original Message----- From: openssl-dev > [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell > Sent: Thursday, March 23, 2017 4:09 PM To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH > > > > 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 certificates. >> I cannot pin point the code in openssl with this regard. > > Are you able to create a simple reproducer demonstrating the problem > with the callback? > > Matt > -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf_Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e= From levitte at openssl.org Thu Mar 23 14:00:38 2017 From: levitte at openssl.org (Richard Levitte) Date: Thu, 23 Mar 2017 15:00:38 +0100 (CET) Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A10781E@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A1077F2@AZ-FFEXMB03.global.avaya.com> <3fab20f8-b60c-6edc-7922-e184000c987c@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10781E@AZ-FFEXMB03.global.avaya.com> Message-ID: <20170323.150038.1594136336870474788.levitte@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 together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out. Cheers, Richard In message <25D2EC755404B4409F263AC6D050FEBB2A10781E at AZ-FFEXMB03.global.avaya.com> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" said: darshanmody> Matt, darshanmody> darshanmody> Below is the scenario. darshanmody> darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain. darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app. darshanmody> 3. Connect client with certificates that server does not trust. darshanmody> 4. The connections from client to server fails darshanmody> darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved. darshanmody> darshanmody> Hope this helps darshanmody> darshanmody> Thanks darshanmody> Darshan darshanmody> darshanmody> -----Original Message----- darshanmody> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell darshanmody> Sent: Thursday, March 23, 2017 6:55 PM darshanmody> To: openssl-dev at openssl.org darshanmody> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH darshanmody> darshanmody> darshanmody> darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote: darshanmody> > Can you further elaborate? darshanmody> > darshanmody> > What we did is to create a TLS connection and with invalid darshanmody> > certificates from the client and server on verification would reject darshanmody> > the certificate. The cipher negotiated was ECDHE cipher between client darshanmody> > and server. darshanmody> > darshanmody> > This was done with load (multiple while 1 script trying to connect to darshanmody> > server using invalid certificates and in course of time the memory was darshanmody> > increasing). darshanmody> darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. darshanmody> darshanmody> Matt darshanmody> darshanmody> darshanmody> > darshanmody> > Thanks Darshan darshanmody> > darshanmody> > -----Original Message----- From: openssl-dev darshanmody> > [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: openssl-dev at openssl.org darshanmody> > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH darshanmody> > darshanmody> > darshanmody> > darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: darshanmody> >> Matt, darshanmody> >> darshanmody> >> Even after accounting for the EC_KEY we still observe some leak. darshanmody> >> The leak started after we started using supporting EC with darshanmody> >> callback SSL_set_tmp_ecdh_callback(). darshanmody> >> darshanmody> >> The core dump shows the string data of the far-end certificates. darshanmody> >> I cannot pin point the code in openssl with this regard. darshanmody> > darshanmody> > Are you able to create a simple reproducer demonstrating the problem darshanmody> > with the callback? darshanmody> > darshanmody> > Matt darshanmody> > darshanmody> -- darshanmody> openssl-dev mailing list darshanmody> To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf_Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e= darshanmody> -- darshanmody> openssl-dev mailing list darshanmody> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev darshanmody> From darshanmody at avaya.com Thu Mar 23 14:10:18 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Thu, 23 Mar 2017 14:10:18 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <20170323.150038.1594136336870474788.levitte@openssl.org> References: <25D2EC755404B4409F263AC6D050FEBB2A1077F2@AZ-FFEXMB03.global.avaya.com> <3fab20f8-b60c-6edc-7922-e184000c987c@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10781E@AZ-FFEXMB03.global.avaya.com> <20170323.150038.1594136336870474788.levitte@openssl.org> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A107853@AZ-FFEXMB03.global.avaya.com> 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-bounces at openssl.org] On Behalf Of Richard Levitte Sent: Thursday, March 23, 2017 7:31 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH 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 together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out. Cheers, Richard In message <25D2EC755404B4409F263AC6D050FEBB2A10781E at AZ-FFEXMB03.global.avaya.com> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" said: darshanmody> Matt, darshanmody> darshanmody> Below is the scenario. darshanmody> darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain. darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app. darshanmody> 3. Connect client with certificates that server does not trust. darshanmody> 4. The connections from client to server fails darshanmody> darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved. darshanmody> darshanmody> Hope this helps darshanmody> darshanmody> Thanks darshanmody> Darshan darshanmody> darshanmody> -----Original Message----- darshanmody> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] darshanmody> On Behalf Of Matt Caswell darshanmody> Sent: Thursday, March 23, 2017 6:55 PM darshanmody> To: openssl-dev at openssl.org darshanmody> Subject: Re: [openssl-dev] Memory leak in application when darshanmody> we use ECDH darshanmody> darshanmody> darshanmody> darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote: darshanmody> > Can you further elaborate? darshanmody> > darshanmody> > What we did is to create a TLS connection and with darshanmody> > invalid certificates from the client and server on darshanmody> > verification would reject the certificate. The cipher darshanmody> > negotiated was ECDHE cipher between client and server. darshanmody> > darshanmody> > This was done with load (multiple while 1 script trying darshanmody> > to connect to server using invalid certificates and in darshanmody> > course of time the memory was increasing). darshanmody> darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. darshanmody> darshanmody> Matt darshanmody> darshanmody> darshanmody> > darshanmody> > Thanks Darshan darshanmody> > darshanmody> > -----Original Message----- From: openssl-dev darshanmody> > [mailto:openssl-dev-bounces at openssl.org] On Behalf Of darshanmody> > Matt Caswell darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: darshanmody> > openssl-dev at openssl.org darshanmody> > Subject: Re: [openssl-dev] Memory leak in application darshanmody> > when we use ECDH darshanmody> > darshanmody> > darshanmody> > darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: darshanmody> >> Matt, darshanmody> >> darshanmody> >> Even after accounting for the EC_KEY we still observe some leak. darshanmody> >> The leak started after we started using supporting EC darshanmody> >> with callback SSL_set_tmp_ecdh_callback(). darshanmody> >> darshanmody> >> The core dump shows the string data of the far-end certificates. darshanmody> >> I cannot pin point the code in openssl with this regard. darshanmody> > darshanmody> > Are you able to create a simple reproducer demonstrating darshanmody> > the problem with the callback? darshanmody> > darshanmody> > Matt darshanmody> > darshanmody> -- darshanmody> openssl-dev mailing list darshanmody> To unsubscribe: darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8 darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK darshanmody> fQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf darshanmody> _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e= darshanmody> -- darshanmody> openssl-dev mailing list darshanmody> To unsubscribe: darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8 darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK darshanmody> fQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q darshanmody> 92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= darshanmody> -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= From rsalz at openssl.org Thu Mar 23 14:41:49 2017 From: rsalz at openssl.org (Rich Salz) Date: Thu, 23 Mar 2017 10:41:49 -0400 Subject: [openssl-dev] License change agreement Message-ID: <20170323144149.GA14513@openssl.org> 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 couple of days we will be sending out emails to as many people as we can. Thank you! From npmccallum at redhat.com Thu Mar 23 15:39:30 2017 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Thu, 23 Mar 2017 11:39:30 -0400 Subject: [openssl-dev] License change agreement In-Reply-To: <20170323144149.GA14513@openssl.org> References: <20170323144149.GA14513@openssl.org> Message-ID: 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, 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 couple of days we will be sending out emails to as many > people as we can. > > Thank you! > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From matt at openssl.org Thu Mar 23 17:57:04 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 23 Mar 2017 17:57:04 +0000 Subject: [openssl-dev] Code Health Tuesday - documentation! Message-ID: <5cac31fb-0d6d-019a-86ec-1d1680121b93@openssl.org> 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 documentation, write it and send us a PR on our github site. Or help us fix incorrect or out-of-date documentation, or broken links, etc. Thanks! Matt FAQ: Q: How do I participate? A: Find something to document. Create a Github pull request and put ?code health? in the title. We?ll be monitoring Github for quick turnaround. Q: Which branches should I target? A: You should target master. If documentation applies to earlier releases then please indicate which ones in the PR. Sometimes there are subtle differences between the different releases, so it may be necessary to create a different PR for older branches. Q: What form should the documentation take? A: All our documentation is in POD file format. Take a look in the doc directory and read a few of the pages to get used to our style. The doc/man3/BIO_printf.pod file is a good, recently written example. If you are providing missing documentation consider whether it should appear in a new POD file, or whether it should be added to an existing one. You can use the "doc-nits" script to run some basic checks on the documentation you have written (run "make doc-nits"). Q: Do you have any tools to find what to document? A: Yes, the doc-nits tool (in the util sub-dir) can provide some useful info: ./util/find-doc-nits ?l (references to non-existing POD pages) ./util/find-doc-nits ?u (all undocumented public functions) From quanah at symas.com Thu Mar 23 17:53:49 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Thu, 23 Mar 2017 10:53:49 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> Message-ID: <2C8B7B7769C9A74C27D90D8E@[192.168.1.19]> --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 details at our most recent blog entry, > https://www.openssl.org/blog The major problem with the existing license is that it conflicts with the GPLv2. 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 not solve these serious problems with how OpenSSL was licensed was ignored. Sad to see that. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From rsalz at akamai.com Thu Mar 23 18:04:11 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 23 Mar 2017 18:04:11 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: <2C8B7B7769C9A74C27D90D8E@[192.168.1.19]> References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@[192.168.1.19]> Message-ID: > 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 problem when this discussion began in July of 2015. It > appears that the feedback that the APL does not solve these serious > problems with how OpenSSL was licensed was ignored. Sad to see that. No it was not ignored. (Just because we disagree doesn't mean we ignore the feedback.) The team felt that the Apache license better met our needs. We can't please all parties, unfortunately. From brian at briansmith.org Thu Mar 23 20:04:25 2017 From: brian at briansmith.org (Brian Smith) Date: Thu, 23 Mar 2017 10:04:25 -1000 Subject: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible Message-ID: 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 the GPL3 license, many people also object to the GPL3 license for important (to them) reasons. Therefore, I think it is important for the OpenSSL license to be compatible with GPL2 too. In the past, I created a library licensed under Apache 2.0, mozilla::pkix. However, Red Hat and Mozilla requested that I additionally license it under the GPLv2 so they could use it in GPLv2-licensed contexts, and I did so. Similarly, LLVM is working on moving to the Apache 2.0 license and they ran into similar problems. They also made the effort to explicitly grant the right to use the relicensed code under the GPLv2. See [1] for details. I think it is important that OpenSSL do something similar to explicitly allow using OpenSSL code under the GPLv2 before any relicensing takes place. Thanks for your consideration. [1] http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html Cheers, Brian -- https://briansmith.org/ From richmoore44 at gmail.com Thu Mar 23 21:33:50 2017 From: richmoore44 at gmail.com (Richard Moore) Date: Thu, 23 Mar 2017 21:33:50 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> Message-ID: On 23 March 2017 at 18:04, Salz, Rich via openssl-dev < openssl-dev at 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 not solve these serious > > problems with how OpenSSL was licensed was ignored. Sad to see that. > > No it was not ignored. (Just because we disagree doesn't mean we ignore > the feedback.) The team felt that the Apache license better met our needs. > ?It's a fairly large elephant in the room that the press release does not address at all though. ?I think it's reasonable to expect some kind of reasoning. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwalten at au1.ibm.com Fri Mar 24 00:37:45 2017 From: pwalten at au1.ibm.com (Peter Waltenberg) Date: Fri, 24 Mar 2017 00:37:45 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: References: , <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> Message-ID: An HTML attachment was scrubbed... URL: From quanah at symas.com Fri Mar 24 02:26:48 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Thu, 23 Mar 2017 19:26:48 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: , <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> Message-ID: --On Friday, March 24, 2017 1:37 AM +0000 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 possible breakage and I think it's a reasonable compromise. Of > course I am biased because I work for the one of the commercial users. Zero people that I know of are saying to switch to the GPL. What is being pointed out is that the incompatibility with the current OpenSSL license with the GPLv2 has been a major problem. Switching to the APLv2 does nothing to resolve that problem. As has been noted, the current advertising is a huge problem with the existing license. One of the reasons that has been a big problem is that it makes the license incompatible with the GPLv2. So on the one hand, getting rid of that clause is great. On the other hand, getting rid of it by switching to the APL is not great, because it doesn't resolve the fundamental problem of being incompatible with the GPLv2. As was noted back when this was brought up in 2015, there are other, better, licenses than the APLv2 which are also GPLv2 compatible. The MPLv2 being an example of such a license. There is also BSD, MIT/X11, etc. The GPLv2 incompatibility of OpenSSL is a major problem. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From uri at ll.mit.edu Fri Mar 24 04:11:48 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 24 Mar 2017 04:11:48 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> Message-ID: <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> 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 > On Mar 23, 2017, at 22:27, Quanah Gibson-Mount wrote: > > --On Friday, March 24, 2017 1:37 AM +0000 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 possible breakage and I think it's a reasonable compromise. Of >> course I am biased because I work for the one of the commercial users. > > Zero people that I know of are saying to switch to the GPL. What is being pointed out is that the incompatibility with the current OpenSSL license with the GPLv2 has been a major problem. Switching to the APLv2 does nothing to resolve that problem. As has been noted, the current advertising is a huge problem with the existing license. One of the reasons that has been a big problem is that it makes the license incompatible with the GPLv2. So on the one hand, getting rid of that clause is great. On the other hand, getting rid of it by switching to the APL is not great, because it doesn't resolve the fundamental problem of being incompatible with the GPLv2. > > As was noted back when this was brought up in 2015, there are other, better, licenses than the APLv2 which are also GPLv2 compatible. The MPLv2 being an example of such a license. There is also BSD, MIT/X11, etc. The GPLv2 incompatibility of OpenSSL is a major problem. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4223 bytes Desc: not available URL: From otto at drijf.net Fri Mar 24 06:48:58 2017 From: otto at drijf.net (Otto Moerbeek) Date: Fri, 24 Mar 2017 07:48:58 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> Message-ID: <20170324064858.GN70789@colo.drijf.net> On Fri, Mar 24, 2017 at 04:11:48AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > 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. I like to mention that any license change cannot be made based on a majority vote or any other method other than getting each author (or its legal representative) to *explicitly* allow the change. The method of "nothing heard equals consent" is not valid in any jurisdiction I know of. While I'm not a contributor (I think I only sent in a small diff years ago), I would like to stress that the planned relicensing procedure is not legal and can be challenged in court. -Otto From meissner at suse.de Fri Mar 24 07:21:49 2017 From: meissner at suse.de (Marcus Meissner) Date: Fri, 24 Mar 2017 08:21:49 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324064858.GN70789@colo.drijf.net> References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> Message-ID: <20170324072149.GC3856@suse.de> On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote: > On Fri, Mar 24, 2017 at 04:11:48AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > > > 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. > > I like to mention that any license change cannot be made based on a > majority vote or any other method other than getting each author (or > its legal representative) to *explicitly* allow the change. The method > of "nothing heard equals consent" is not valid in any jurisdiction I > know of. > > While I'm not a contributor (I think I only sent in a small diff years > ago), I would like to stress that the planned relicensing procedure is > not legal and can be challenged in court. Well, emails were sent yesterday out to _all_ contributors for ack/deny the change. Ciao, Marcus From otto at drijf.net Fri Mar 24 07:36:02 2017 From: otto at drijf.net (Otto Moerbeek) Date: Fri, 24 Mar 2017 08:36:02 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324072149.GC3856@suse.de> References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> Message-ID: <20170324073602.GO70789@colo.drijf.net> On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote: > On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote: > > On Fri, Mar 24, 2017 at 04:11:48AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > > > > > 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. > > > > I like to mention that any license change cannot be made based on a > > majority vote or any other method other than getting each author (or > > its legal representative) to *explicitly* allow the change. The method > > of "nothing heard equals consent" is not valid in any jurisdiction I > > know of. > > > > While I'm not a contributor (I think I only sent in a small diff years > > ago), I would like to stress that the planned relicensing procedure is > > not legal and can be challenged in court. > > Well, emails were sent yesterday out to _all_ contributors for ack/deny the change. > > Ciao, Marcus > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev Read the last line of the mail, it says the no reactions equals consent. That is the illegal part. -Otto From kurt at roeckx.be Fri Mar 24 08:40:16 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 24 Mar 2017 09:40:16 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324073602.GO70789@colo.drijf.net> References: <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> <20170324073602.GO70789@colo.drijf.net> Message-ID: <20170324084015.uan4qzvk6yia6jxs@roeckx.be> On Fri, Mar 24, 2017 at 08:36:02AM +0100, Otto Moerbeek wrote: > On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote: > > > On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote: > > > On Fri, Mar 24, 2017 at 04:11:48AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > > > > > > > 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. > > > > > > I like to mention that any license change cannot be made based on a > > > majority vote or any other method other than getting each author (or > > > its legal representative) to *explicitly* allow the change. The method > > > of "nothing heard equals consent" is not valid in any jurisdiction I > > > know of. > > > > > > While I'm not a contributor (I think I only sent in a small diff years > > > ago), I would like to stress that the planned relicensing procedure is > > > not legal and can be challenged in court. > > > > Well, emails were sent yesterday out to _all_ contributors for ack/deny the change. > > Read the last line of the mail, it says the no reactions equals > consent. That is the illegal part. The legal advice we got said that we should do our best to contact people. If we contacted them, they had the possibility to say no. We will give them time and go over all people that didn't reply to try to reach them. But if they don't reply, as said, we will assume they have no problem with the license change. If at some later point in time they do come forward and say no, we will deal with that at that time. Kurt From otto at drijf.net Fri Mar 24 09:06:53 2017 From: otto at drijf.net (Otto Moerbeek) Date: Fri, 24 Mar 2017 10:06:53 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324084015.uan4qzvk6yia6jxs@roeckx.be> References: <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> <20170324073602.GO70789@colo.drijf.net> <20170324084015.uan4qzvk6yia6jxs@roeckx.be> Message-ID: <20170324090653.GP70789@colo.drijf.net> On Fri, Mar 24, 2017 at 09:40:16AM +0100, Kurt Roeckx wrote: > On Fri, Mar 24, 2017 at 08:36:02AM +0100, Otto Moerbeek wrote: > > On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote: > > > > > On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote: > > > > On Fri, Mar 24, 2017 at 04:11:48AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > > > > > > > > > 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. > > > > > > > > I like to mention that any license change cannot be made based on a > > > > majority vote or any other method other than getting each author (or > > > > its legal representative) to *explicitly* allow the change. The method > > > > of "nothing heard equals consent" is not valid in any jurisdiction I > > > > know of. > > > > > > > > While I'm not a contributor (I think I only sent in a small diff years > > > > ago), I would like to stress that the planned relicensing procedure is > > > > not legal and can be challenged in court. > > > > > > Well, emails were sent yesterday out to _all_ contributors for ack/deny the change. > > > > Read the last line of the mail, it says the no reactions equals > > consent. That is the illegal part. > > The legal advice we got said that we should do our best to contact > people. If we contacted them, they had the possibility to say no. > We will give them time and go over all people that didn't reply to > try to reach them. > > But if they don't reply, as said, we will assume they have no > problem with the license change. If at some later point in time > they do come forward and say no, we will deal with that at that > time. > > > Kurt Probably illegal and definitely immoral, in my opinion. Copyright law exists to protect authors from these kind of practises. -Otto From uri at ll.mit.edu Fri Mar 24 11:53:10 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 24 Mar 2017 11:53:10 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324090653.GP70789@colo.drijf.net> References: <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> <20170324073602.GO70789@colo.drijf.net> <20170324084015.uan4qzvk6yia6jxs@roeckx.be> <20170324090653.GP70789@colo.drijf.net> Message-ID: I personally think this issue is being blown way out of proportion and beyond the boundary of reason. Regards, Uri Sent from my iPhone > On Mar 24, 2017, at 05:07, Otto Moerbeek wrote: > >> On Fri, Mar 24, 2017 at 09:40:16AM +0100, Kurt Roeckx wrote: >> >>> On Fri, Mar 24, 2017 at 08:36:02AM +0100, Otto Moerbeek wrote: >>>> On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote: >>>> >>>>> On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote: >>>>>> On Fri, Mar 24, 2017 at 04:11:48AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: >>>>>> >>>>>> 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. >>>>> >>>>> I like to mention that any license change cannot be made based on a >>>>> majority vote or any other method other than getting each author (or >>>>> its legal representative) to *explicitly* allow the change. The method >>>>> of "nothing heard equals consent" is not valid in any jurisdiction I >>>>> know of. >>>>> >>>>> While I'm not a contributor (I think I only sent in a small diff years >>>>> ago), I would like to stress that the planned relicensing procedure is >>>>> not legal and can be challenged in court. >>>> >>>> Well, emails were sent yesterday out to _all_ contributors for ack/deny the change. >>> >>> Read the last line of the mail, it says the no reactions equals >>> consent. That is the illegal part. >> >> The legal advice we got said that we should do our best to contact >> people. If we contacted them, they had the possibility to say no. >> We will give them time and go over all people that didn't reply to >> try to reach them. >> >> But if they don't reply, as said, we will assume they have no >> problem with the license change. If at some later point in time >> they do come forward and say no, we will deal with that at that >> time. >> >> >> Kurt > > Probably illegal and definitely immoral, in my opinion. Copyright law > exists to protect authors from these kind of practises. > > -Otto > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4223 bytes Desc: not available URL: From otto at drijf.net Fri Mar 24 12:14:35 2017 From: otto at drijf.net (Otto Moerbeek) Date: Fri, 24 Mar 2017 13:14:35 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: References: <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> <20170324073602.GO70789@colo.drijf.net> <20170324084015.uan4qzvk6yia6jxs@roeckx.be> <20170324090653.GP70789@colo.drijf.net> Message-ID: <20170324121435.GQ70789@colo.drijf.net> On Fri, Mar 24, 2017 at 11:53:10AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > I personally think this issue is being blown way out of proportion and beyond the boundary of reason. > > Regards, > Uri Is it reasonable to step on the rights of authors with the backing of large corporations? Individual authors that might have chosen to change email address or are unable to be contacted for other reasons? It is sad to see the corporate giants dictate the policies of yet another open source project, without regard for the spirit of copyright law which is to protect the individual author. -Otto From levitte at openssl.org Fri Mar 24 12:29:53 2017 From: levitte at openssl.org (Richard Levitte) Date: Fri, 24 Mar 2017 13:29:53 +0100 (CET) Subject: [openssl-dev] License change agreement In-Reply-To: <20170324121435.GQ70789@colo.drijf.net> References: <20170324090653.GP70789@colo.drijf.net> <20170324121435.GQ70789@colo.drijf.net> Message-ID: <20170324.132953.1073290708742030909.levitte@openssl.org> In message <20170324121435.GQ70789 at colo.drijf.net> on Fri, 24 Mar 2017 13:14:35 +0100, Otto Moerbeek said: otto> On Fri, Mar 24, 2017 at 11:53:10AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: otto> otto> > I personally think this issue is being blown way out of proportion and beyond the boundary of reason. otto> > otto> > Regards, otto> > Uri otto> otto> Is it reasonable to step on the rights of authors with the backing of otto> large corporations? Individual authors that might have chosen to otto> change email address or are unable to be contacted for other reasons? otto> otto> It is sad to see the corporate giants dictate the policies of yet otto> another open source project, without regard for the spirit of otto> copyright law which is to protect the individual author. If I'm reading you correctly, *any* license change faces the exact same problem. My interpretation of what you say is that unless we can successfully reach all contributors, no exception, we're stuck with the current license, probably for life. Am I reading you correctly? -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From otto at drijf.net Fri Mar 24 12:36:57 2017 From: otto at drijf.net (Otto Moerbeek) Date: Fri, 24 Mar 2017 13:36:57 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324.132953.1073290708742030909.levitte@openssl.org> References: <20170324090653.GP70789@colo.drijf.net> <20170324121435.GQ70789@colo.drijf.net> <20170324.132953.1073290708742030909.levitte@openssl.org> Message-ID: <20170324123657.GR70789@colo.drijf.net> On Fri, Mar 24, 2017 at 01:29:53PM +0100, Richard Levitte wrote: > In message <20170324121435.GQ70789 at colo.drijf.net> on Fri, 24 Mar 2017 13:14:35 +0100, Otto Moerbeek said: > > otto> On Fri, Mar 24, 2017 at 11:53:10AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > otto> > otto> > I personally think this issue is being blown way out of proportion and beyond the boundary of reason. > otto> > > otto> > Regards, > otto> > Uri > otto> > otto> Is it reasonable to step on the rights of authors with the backing of > otto> large corporations? Individual authors that might have chosen to > otto> change email address or are unable to be contacted for other reasons? > otto> > otto> It is sad to see the corporate giants dictate the policies of yet > otto> another open source project, without regard for the spirit of > otto> copyright law which is to protect the individual author. > > If I'm reading you correctly, *any* license change faces the exact > same problem. My interpretation of what you say is that unless we can > successfully reach all contributors, no exception, we're stuck with > the current license, probably for life. > > Am I reading you correctly? Yes, the default is "no, you're not allowed to change the license", not "yes, you are allowed". If you do not have explicit permission, the contribution(s) of an auther must remain under the existing license or be removed. If you do no want that, you should rewrite that piece so you can attach your preferred license as author. -Otto From richmoore44 at gmail.com Fri Mar 24 12:37:01 2017 From: richmoore44 at gmail.com (Richard Moore) Date: Fri, 24 Mar 2017 12:37:01 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> Message-ID: On 24 March 2017 at 02:26, Quanah Gibson-Mount wrote: > --On Friday, March 24, 2017 1:37 AM +0000 Peter Waltenberg < > pwalten at au1.ibm.com> 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 possible breakage and I think it's a reasonable compromise. Of >> course I am biased because I work for the one of the commercial users. >> > > Zero people that I know of are saying to switch to the GPL. What is being > pointed out is that the incompatibility with the current OpenSSL license > with the GPLv2 has been a major problem. Switching to the APLv2 does > nothing to resolve that problem. As has been noted, the current > advertising is a huge problem with the existing license. One of the > reasons that has been a big problem is that it makes the license > incompatible with the GPLv2. So on the one hand, getting rid of that > clause is great. On the other hand, getting rid of it by switching to the > APL is not great, because it doesn't resolve the fundamental problem of > being incompatible with the GPLv2. > > As was noted back when this was brought up in 2015, there are other, > better, licenses than the APLv2 which are also GPLv2 compatible. The MPLv2 > being an example of such a license. There is also BSD, MIT/X11, etc. The > GPLv2 incompatibility of OpenSSL is a major problem. ?Indeed, I don't think GPL2 itself would be a good choice. Cheers Rich.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From stse+openssl at fsing.rootsland.net Fri Mar 24 12:38:54 2017 From: stse+openssl at fsing.rootsland.net (Stephan Seitz) Date: Fri, 24 Mar 2017 13:38:54 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324.132953.1073290708742030909.levitte@openssl.org> References: <20170324090653.GP70789@colo.drijf.net> <20170324121435.GQ70789@colo.drijf.net> <20170324.132953.1073290708742030909.levitte@openssl.org> Message-ID: <20170324T133449.GA.08e2c.stse@fsing.rootsland.net> On Fr, M?r 24, 2017 at 01:29:53 +0100, Richard Levitte wrote: >If I'm reading you correctly, *any* license change faces the exact >same problem. My interpretation of what you say is that unless we can >successfully reach all contributors, no exception, we're stuck with >the current license, probably for life. While I think you?re reading him correctly, I don?t see a big problem. I mean, if the people you are mailing don?t accept die license change for their code part you are stuck with the same problem. If this works the same way as in other projects this code parts have to be rewritten. Shade and sweet water! Stephan -- | Public Keys: http://fsing.rootsland.net/~stse/keys.html | -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3735 bytes Desc: not available URL: From rsalz at akamai.com Fri Mar 24 13:17:26 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 24 Mar 2017 13:17:26 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: References: , <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> Message-ID: <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> > As was noted back when this was brought up in 2015, there are other, better, > licenses than the APLv2 which are also GPLv2 compatible. The MPLv2 being > an example of such a license. There is also BSD, MIT/X11, etc. The > GPLv2 incompatibility of OpenSSL is a major problem. Better in one dimension, not in the multiple dimensions that we are concerned about. For example, one of the major things that is an issue for GPLv2 is the patent protection. Patent protection is important to us. At least now we're compatible with GPL3, which is hopefully seen as a major step forward. Yes, it is too bad we can't please all communities right now. From dirkx at webweaving.org Fri Mar 24 13:11:31 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Fri, 24 Mar 2017 14:11:31 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324121435.GQ70789@colo.drijf.net> References: <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> <20170324073602.GO70789@colo.drijf.net> <20170324084015.uan4qzvk6yia6jxs@roeckx.be> <20170324090653.GP70789@colo.drijf.net> <20170324121435.GQ70789@colo.drijf.net> Message-ID: <38B561E4-7EAC-47F9-92D5-60BD9ADDBC77@webweaving.org> > On 24 Mar 2017, at 13:14, Otto Moerbeek wrote: > > On Fri, Mar 24, 2017 at 11:53:10AM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > >> I personally think this issue is being blown way out of proportion and beyond the boundary of reason. >> >> Regards, >> Uri > > Is it reasonable to step on the rights of authors with the backing of > large corporations? I personally do not see this as something led, backed or driven by the large corporation. Rather, I see a community of developers, do a very reasonable, timely and sensible job to get their house in order; adapt to the realities of modern society - and thus allow the community to continue to operate as it wants in a changed world. We understand a lot more about IPR, CLAs, patens and (software) licenses (their interaction with business and governance processes) than we did 30 years ago. And just like we consider retiring support for say a PDP-11, AIX or SunOS & old compiler cruft ? so do our licenses need maintenance. > Individual authors that might have chosen to > change email address or are unable to be contacted for other reasons? And as all things in life - this is not a black or white thing - but one where you need to trade one type of risk versus that of another. Long term health of the community is important; as are old contributions made once to that community. But to an outsider or reasonably observer - neither is done without context or absolute. Total stagnation is as much a risk as blindly pushing through a change unilaterally. To me it seems that OpenSSL is doing a commendable job trying to find a balance. And ultimately a large part of the metric of success is wether this community survives; and continues to see the amplification loop of having its code use and thus garnering resources to keep the code usable work. Like bitrot - outdated & outmoded licenses too are an impediment too for this. Also - know that outsiders who have to access the risks of these license changes won?t see this as a black and white thing - and are perfectly used to trade the advantages of a known license with the residuals of less than perfect provenance. We do that all the time. With kind regards, Dw. From quanah at symas.com Fri Mar 24 15:14:25 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 24 Mar 2017 08:14:25 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: , <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: --On Friday, March 24, 2017 2:17 PM +0000 "Salz, Rich" wrote: >> As was noted back when this was brought up in 2015, there are other, >> better, licenses than the APLv2 which are also GPLv2 compatible. The >> MPLv2 being an example of such a license. There is also BSD, MIT/X11, >> etc. The GPLv2 incompatibility of OpenSSL is a major problem. > > Better in one dimension, not in the multiple dimensions that we are > concerned about. For example, one of the major things that is an issue > for GPLv2 is the patent protection. Patent protection is important to > us. At least now we're compatible with GPL3, which is hopefully seen as > a major step forward. > > Yes, it is too bad we can't please all communities right now. Yes, you brought patent protection in 2015, and in 2015, I pointed out that the MPLv2 also has patent protections, but here's a refresher: The MPLv2 of course has the advantage of being compatible with both the GPLv2 and the GPLv3, etc. I.e., it has much broader compatibility than the APLv2. In 2 years time, I've yet to see one valid argument to using the APLv2 vs the MPLv2 originate from the OpenSSL team. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From dirkx at webweaving.org Fri Mar 24 16:00:11 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Fri, 24 Mar 2017 17:00:11 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> > On 24 Mar 2017, at 16:14, Quanah Gibson-Mount wrote: > > --On Friday, March 24, 2017 2:17 PM +0000 "Salz, Rich" wrote: > >>> As was noted back when this was brought up in 2015, there are other, >>> better, licenses than the APLv2 which are also GPLv2 compatible. The >>> MPLv2 being an example of such a license. There is also BSD, MIT/X11, >>> etc. The GPLv2 incompatibility of OpenSSL is a major problem. >> >> Better in one dimension, not in the multiple dimensions that we are >> concerned about. For example, one of the major things that is an issue >> for GPLv2 is the patent protection. Patent protection is important to >> us. At least now we're compatible with GPL3, which is hopefully seen as >> a major step forward. >> >> Yes, it is too bad we can't please all communities right now. > > Yes, you brought patent protection in 2015, and in 2015, I pointed out that the MPLv2 also has patent protections, but here's a refresher: > > > > > The MPLv2 of course has the advantage of being compatible with both the GPLv2 and the GPLv3, etc. I.e., it has much broader compatibility than the APLv2. > > In 2 years time, I've yet to see one valid argument to using the APLv2 vs the MPLv2 originate from the OpenSSL team. The two licenses are not identical. Specifically the MPL goes one step further with respect to the disclosure of the source code* -- The ASL stops just before that - and is more akin to the MIT and BSD licenses. From personal experience - and given how OpenSSL is commonly used as one of many small components in a larger work - that does make (my) live in the real world a lot easer. Dw. *: (though not as far as the Free software licences; it limits it to the code under the MPL itself). From quanah at symas.com Fri Mar 24 16:27:56 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 24 Mar 2017 09:27:56 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> Message-ID: --On Friday, March 24, 2017 6:00 PM +0100 Dirk-Willem van Gulik wrote: >> In 2 years time, I've yet to see one valid argument to using the APLv2 >> vs the MPLv2 originate from the OpenSSL team. > > The two licenses are not identical. > > Specifically the MPL goes one step further with respect to the disclosure > of the source code* -- The ASL stops just before that - and is more akin > to the MIT and BSD licenses. > > From personal experience - and given how OpenSSL is commonly used as one > of many small components in a larger work - that does make (my) live in > the real world a lot easer. > > Dw. > > *: (though not as far as the Free software licences; it limits it to the > code under the MPL itself). Yes, I'm certainly not saying they are the same. But the reasons provided so far by the OpenSSL team have not shown why the APLv2 is a better choice for the downstream consumers of OpensSL vs the MPLv2, and there are definite reasons as to why the APLv2 is problematic. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From rsalz at akamai.com Fri Mar 24 16:40:15 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 24 Mar 2017 16:40:15 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> Message-ID: The required source code disclosures of the MPL are problematic. The fact that the MPL allows distribution under a non-patent-protecting license is problematic. Ok? From quanah at symas.com Fri Mar 24 17:04:30 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 24 Mar 2017 10:04:30 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> Message-ID: --On Friday, March 24, 2017 5:40 PM +0000 "Salz, Rich" wrote: > The required source code disclosures of the MPL are problematic. The > fact that the MPL allows distribution under a non-patent-protecting > license is problematic. > > Ok? Thanks Rich, that's a more useful starting point. Has dual licensing been considered? Both in 2015 and now, the lack of GPLv2 compatibility has shown to be a serious drawback to the APLv2. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From rsalz at akamai.com Fri Mar 24 17:12:30 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 24 Mar 2017 17:12:30 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> Message-ID: <18c72f8f546a470ca754b8b13afae5a2@usma1ex-dag1mb1.msg.corp.akamai.com> > Thanks Rich, that's a more useful starting point. Has dual licensing been > considered? Both in 2015 and now, the lack of GPLv2 compatibility has > shown to be a serious drawback to the APLv2. Dual licensing means that it is also available under a no-patent-protection license which is an issue for us. From quanah at symas.com Fri Mar 24 17:18:40 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 24 Mar 2017 10:18:40 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> <18c72f8f546a470ca754b8b13afae5a2@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <77D76C550A770F9A09E0F2B6@[192.168.1.19]> --On Friday, March 24, 2017 6:12 PM +0000 "Salz, Rich" wrote: >> Thanks Rich, that's a more useful starting point. Has dual licensing >> been considered? Both in 2015 and now, the lack of GPLv2 compatibility >> has shown to be a serious drawback to the APLv2. > > Dual licensing means that it is also available under a > no-patent-protection license which is an issue for us. APLv2 and MPLv2 both have patent protections. How would a dual license of APL+MPL result in a no-patent-protection license? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From rsalz at akamai.com Fri Mar 24 17:30:40 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 24 Mar 2017 17:30:40 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: <77D76C550A770F9A09E0F2B6@[192.168.1.19]> References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> <18c72f8f546a470ca754b8b13afae5a2@usma1ex-dag1mb1.msg.corp.akamai.com> <77D76C550A770F9A09E0F2B6@[192.168.1.19]> Message-ID: <61896f7c45cb4cb482e8f05c167bf105@usma1ex-dag1mb1.msg.corp.akamai.com> > > Dual licensing means that it is also available under a > > no-patent-protection license which is an issue for us. > > APLv2 and MPLv2 both have patent protections. How would a dual license of > APL+MPL result in a no-patent-protection license? MPL allows GPL which has no patent protection. From kurt at roeckx.be Fri Mar 24 17:47:54 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 24 Mar 2017 18:47:54 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <77D76C550A770F9A09E0F2B6@[192.168.1.19]> References: <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> <18c72f8f546a470ca754b8b13afae5a2@usma1ex-dag1mb1.msg.corp.akamai.com> <77D76C550A770F9A09E0F2B6@[192.168.1.19]> Message-ID: <20170324174754.bqbxh2p5jaik76rn@roeckx.be> On Fri, Mar 24, 2017 at 10:18:40AM -0700, Quanah Gibson-Mount wrote: > --On Friday, March 24, 2017 6:12 PM +0000 "Salz, Rich" > wrote: > > > > Thanks Rich, that's a more useful starting point. Has dual licensing > > > been considered? Both in 2015 and now, the lack of GPLv2 compatibility > > > has shown to be a serious drawback to the APLv2. > > > > Dual licensing means that it is also available under a > > no-patent-protection license which is an issue for us. > > APLv2 and MPLv2 both have patent protections. How would a dual license of > APL+MPL result in a no-patent-protection license? As far as I understand the MPLv2 is only compatible with the GPLv2 in a very specific case which makes it not useful for people that would actually want to link their application with it. Kurt From James.Bottomley at HansenPartnership.com Fri Mar 24 18:30:19 2017 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 24 Mar 2017 11:30:19 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324090653.GP70789@colo.drijf.net> References: <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> <20170324073602.GO70789@colo.drijf.net> <20170324084015.uan4qzvk6yia6jxs@roeckx.be> <20170324090653.GP70789@colo.drijf.net> Message-ID: <1490380219.2426.15.camel@HansenPartnership.com> On Fri, 2017-03-24 at 10:06 +0100, Otto Moerbeek wrote: > On Fri, Mar 24, 2017 at 09:40:16AM +0100, Kurt Roeckx wrote: > > > On Fri, Mar 24, 2017 at 08:36:02AM +0100, Otto Moerbeek wrote: > > > On Fri, Mar 24, 2017 at 08:21:49AM +0100, Marcus Meissner wrote: > > > > > > > On Fri, Mar 24, 2017 at 07:48:58AM +0100, Otto Moerbeek wrote: > > > > > On Fri, Mar 24, 2017 at 04:11:48AM +0000, Blumenthal, Uri - > > > > > 0553 - MITLL wrote: > > > > > > > > > > > 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. > > > > > > > > > > I like to mention that any license change cannot be made > > > > > based on a majority vote or any other method other than > > > > > getting each author (or its legal representative) to > > > > > *explicitly* allow the change. The method of "nothing heard > > > > > equals consent" is not valid in any jurisdiction I know of. > > > > > > > > > > While I'm not a contributor (I think I only sent in a small > > > > > diff years ago), I would like to stress that the planned > > > > > relicensing procedure is not legal and can be challenged in > > > > > court. > > > > > > > > Well, emails were sent yesterday out to _all_ contributors for > > > > ack/deny the change. > > > > > > Read the last line of the mail, it says the no reactions equals > > > consent. That is the illegal part. > > > > The legal advice we got said that we should do our best to contact > > people. If we contacted them, they had the possibility to say no. > > We will give them time and go over all people that didn't reply to > > try to reach them. > > > > But if they don't reply, as said, we will assume they have no > > problem with the license change. If at some later point in time > > they do come forward and say no, we will deal with that at that > > time. > > > > > > Kurt > > Probably illegal and definitely immoral, in my opinion. Copyright law > exists to protect authors from these kind of practises. I think you misunderstand the legal situation. Provided notice is sufficiently widely distributed and a reasonable period is allowed for objections it will become an estoppel issue after the licence is changed, which means anyone trying to object after the fact of the change will have to get a court order based on irreperable harm and show a good faith reason for not being able to object in the time period allowed. In the US, this sort of notice plus period for objection is standard for quite a few suits and the range of things which qualify as "good faith reason" are correspondingly very limited. James From quanah at symas.com Fri Mar 24 18:39:19 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 24 Mar 2017 11:39:19 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> <18c72f8f546a470ca754b8b13afae5a2@usma1ex-dag1mb1.msg.corp.akamai.com> <77D76C550A770F9A09E0F2B6@[192.168.1.19]> <61896f7c45cb4cb482e8f05c167bf105@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1E6BB80AEE8D79F84AC3AD76@[192.168.1.19]> --On Friday, March 24, 2017 6:30 PM +0000 "Salz, Rich" wrote: >> > Dual licensing means that it is also available under a >> > no-patent-protection license which is an issue for us. >> >> APLv2 and MPLv2 both have patent protections. How would a dual license >> of APL+MPL result in a no-patent-protection license? > > MPL allows GPL which has no patent protection. It doesn't mean the code is no longer covered by the MPL. See , "Unmodified MPL-licensed Files - MPL-only". --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From quanah at symas.com Fri Mar 24 18:43:17 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 24 Mar 2017 11:43:17 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> <18c72f8f546a470ca754b8b13afae5a2@usma1ex-dag1mb1.msg.corp.akamai.com> <77D76C550A770F9A09E0F2B6@[192.168.1.19]> <20170324174754.bqbxh2p5jaik76rn@roeckx.be> Message-ID: --On Friday, March 24, 2017 7:47 PM +0100 Kurt Roeckx wrote: > On Fri, Mar 24, 2017 at 10:18:40AM -0700, Quanah Gibson-Mount wrote: >> --On Friday, March 24, 2017 6:12 PM +0000 "Salz, Rich" >> wrote: >> >> > > Thanks Rich, that's a more useful starting point. Has dual licensing >> > > been considered? Both in 2015 and now, the lack of GPLv2 >> > > compatibility has shown to be a serious drawback to the APLv2. >> > >> > Dual licensing means that it is also available under a >> > no-patent-protection license which is an issue for us. >> >> APLv2 and MPLv2 both have patent protections. How would a dual license >> of APL+MPL result in a no-patent-protection license? > > As far as I understand the MPLv2 is only compatible with the GPLv2 > in a very specific case which makes it not useful for people that > would actually want to link their application with it. Reference? I certainly don't see that in --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From James.Bottomley at HansenPartnership.com Fri Mar 24 18:43:48 2017 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 24 Mar 2017 11:43:48 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> References: , <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1490381028.2426.24.camel@HansenPartnership.com> On Fri, 2017-03-24 at 13:17 +0000, Salz, Rich via openssl-dev wrote: > > As was noted back when this was brought up in 2015, there are > > other, better, licenses than the APLv2 which are also GPLv2 > > compatible. The MPLv2 being an example of such a license. There > > is also BSD, MIT/X11, etc. The GPLv2 incompatibility of OpenSSL > > is a major problem. > > Better in one dimension, not in the multiple dimensions that we are > concerned about. For example, one of the major things that is an > issue for GPLv2 is the patent protection. Patent protection is > important to us. At least now we're compatible with GPL3, which is > hopefully seen as a major step forward. There seems to be a misunderstanding here: for starters licensing any library under GPLv2 is problematic because of the viral nature (it's mostly done as a ploy for open core business models), so I'm assuming you mean LGPLv2 (or 3) which would allow linking to non GPL code? Secondly the GPLv2 family of licences has strong implicit patent licences which GPLv3 made explicit. In terms of broad protection there's no real difference (as long as the patent owner ships the code, they can't sue). Explicit gives you a measure of protection on contributions if the owner leaves the community for some reason, but it's a much weaker protection than if they remain in the community (applies only to contributions as opposed to entire code base). James > Yes, it is too bad we can't please all communities right now. From rsalz at akamai.com Fri Mar 24 18:46:34 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 24 Mar 2017 18:46:34 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: <1E6BB80AEE8D79F84AC3AD76@[192.168.1.19]> References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <6a6c6f77ce3346b7b6d421e3743bd2cf@usma1ex-dag1mb1.msg.corp.akamai.com> <9FB4E552-FA72-4411-B5AF-39DF55C3A6C2@webweaving.org> <18c72f8f546a470ca754b8b13afae5a2@usma1ex-dag1mb1.msg.corp.akamai.com> <77D76C550A770F9A09E0F2B6@[192.168.1.19]> <61896f7c45cb4cb482e8f05c167bf105@usma1ex-dag1mb1.msg.corp.akamai.com> <1E6BB80AEE8D79F84AC3AD76@[192.168.1.19]> Message-ID: <08de5895e2c24195b7c4e9195e66ba4a@usma1ex-dag1mb1.msg.corp.akamai.com> > It doesn't mean the code is no longer covered by the MPL. See > , That is very complicated as can be seen by the multiple cases, all of which we would expect to apply to OpenSSL at one point or another. Our legal advice discouraged this. Our discussions with various folks did not encourage it. At any rate, GPLv2 folks can continue to use the current code, dual-license or add an exception for their application, decide to agree with the ASF that it's okay, or use alternatives such as GnuTLS. Again, we are sorry that we cannot solve all issues at this time. We didn't create this situation, we have to live with it like everyone else. From kurt at roeckx.be Fri Mar 24 18:55:05 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 24 Mar 2017 19:55:05 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: References: <18c72f8f546a470ca754b8b13afae5a2@usma1ex-dag1mb1.msg.corp.akamai.com> <77D76C550A770F9A09E0F2B6@[192.168.1.19]> <20170324174754.bqbxh2p5jaik76rn@roeckx.be> Message-ID: <20170324185505.ymqbw2joz5xm3qcy@roeckx.be> On Fri, Mar 24, 2017 at 11:43:17AM -0700, Quanah Gibson-Mount wrote: > --On Friday, March 24, 2017 7:47 PM +0100 Kurt Roeckx > wrote: > > > On Fri, Mar 24, 2017 at 10:18:40AM -0700, Quanah Gibson-Mount wrote: > > > --On Friday, March 24, 2017 6:12 PM +0000 "Salz, Rich" > > > wrote: > > > > > > > > Thanks Rich, that's a more useful starting point. Has dual licensing > > > > > been considered? Both in 2015 and now, the lack of GPLv2 > > > > > compatibility has shown to be a serious drawback to the APLv2. > > > > > > > > Dual licensing means that it is also available under a > > > > no-patent-protection license which is an issue for us. > > > > > > APLv2 and MPLv2 both have patent protections. How would a dual license > > > of APL+MPL result in a no-patent-protection license? > > > > As far as I understand the MPLv2 is only compatible with the GPLv2 > > in a very specific case which makes it not useful for people that > > would actually want to link their application with it. > > Reference? I certainly don't see that in > Then I suggest you read that FAQ again. Kurt From quanah at symas.com Fri Mar 24 19:03:28 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 24 Mar 2017 12:03:28 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> <20170324073602.GO70789@colo.drijf.net> <20170324084015.uan4qzvk6yia6jxs@roeckx.be> <20170324090653.GP70789@colo.drijf.net> <1490380219.2426.15.camel@HansenPartnership.com> Message-ID: --On Friday, March 24, 2017 12:30 PM -0700 James Bottomley wrote: >> Probably illegal and definitely immoral, in my opinion. Copyright law >> exists to protect authors from these kind of practises. > > I think you misunderstand the legal situation. Provided notice is > sufficiently widely distributed and a reasonable period is allowed for > objections it will become an estoppel issue after the licence is > changed, which means anyone trying to object after the fact of the > change will have to get a court order based on irreperable harm and > show a good faith reason for not being able to object in the time > period allowed. In the US, this sort of notice plus period for > objection is standard for quite a few suits and the range of things > which qualify as "good faith reason" are correspondingly very limited. It's not clear to me that that's correct. From (See update), it appears you need an explicit 95% permission rate to legally relicense and zero objections. So far one objection has already surfaced. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From rsalz at akamai.com Fri Mar 24 19:05:35 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 24 Mar 2017 19:05:35 +0000 Subject: [openssl-dev] License change agreement In-Reply-To: References: <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> <20170324073602.GO70789@colo.drijf.net> <20170324084015.uan4qzvk6yia6jxs@roeckx.be> <20170324090653.GP70789@colo.drijf.net> <1490380219.2426.15.camel@HansenPartnership.com> Message-ID: <0588e9009da347ad824d224090f464cb@usma1ex-dag1mb1.msg.corp.akamai.com> > It's not clear to me that that's correct. From > (See update), it appears you need an > explicit 95% permission rate to legally relicense and zero objections. So > far one objection has already surfaced. And code from people who object will most likely have their commits reverted making their objection moot. From fw at deneb.enyo.de Fri Mar 24 19:02:25 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 24 Mar 2017 20:02:25 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: (Quanah Gibson-Mount's message of "Thu\, 23 Mar 2017 19\:26\:48 -0700") References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> Message-ID: <87k27ewla6.fsf@mid.deneb.enyo.de> * Quanah Gibson-Mount: > Zero people that I know of are saying to switch to the GPL. What is > being pointed out is that the incompatibility with the current > OpenSSL license with the GPLv2 has been a major problem. The alleged incompatibility of OpenSSL with the GPLv2 has been used to promote GNUTLS in the past (and to a much lesser extent, a certain crypto consolidation effort intending to switch everything to NSS). But GNUTLS has since left the GNU project, and I'm not aware of anyone on the distribution side still saying that the old OpenSSL license (particular when used as a dynamically-linked system library) and the GPLv2 are incompatible. It's just not considered a problem anymore. From quanah at symas.com Fri Mar 24 19:16:33 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 24 Mar 2017 12:16:33 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <87k27ewla6.fsf@mid.deneb.enyo.de> Message-ID: <47B628FBEEE3D3485542B1E6@[192.168.1.19]> --On Friday, March 24, 2017 9:02 PM +0100 Florian Weimer wrote: > * Quanah Gibson-Mount: > >> Zero people that I know of are saying to switch to the GPL. What is >> being pointed out is that the incompatibility with the current >> OpenSSL license with the GPLv2 has been a major problem. > > The alleged incompatibility of OpenSSL with the GPLv2 has been used to > promote GNUTLS in the past (and to a much lesser extent, a certain > crypto consolidation effort intending to switch everything to NSS). > But GNUTLS has since left the GNU project, and I'm not aware of anyone > on the distribution side still saying that the old OpenSSL license > (particular when used as a dynamically-linked system library) and the > GPLv2 are incompatible. It's just not considered a problem anymore. So that would imply then that moving to the APL would be a step backward, since it is explicitly GPLv2 incompatible. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From James.Bottomley at HansenPartnership.com Fri Mar 24 19:18:07 2017 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 24 Mar 2017 12:18:07 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> <20170324073602.GO70789@colo.drijf.net> <20170324084015.uan4qzvk6yia6jxs@roeckx.be> <20170324090653.GP70789@colo.drijf.net> <1490380219.2426.15.camel@HansenPartnership.com> Message-ID: <1490383087.2426.38.camel@HansenPartnership.com> On Fri, 2017-03-24 at 12:03 -0700, Quanah Gibson-Mount wrote: > --On Friday, March 24, 2017 12:30 PM -0700 James Bottomley > wrote: > > > > > Probably illegal and definitely immoral, in my opinion. Copyright > > > law > > > exists to protect authors from these kind of practises. > > > > I think you misunderstand the legal situation. Provided notice is > > sufficiently widely distributed and a reasonable period is allowed > > for > > objections it will become an estoppel issue after the licence is > > changed, which means anyone trying to object after the fact of the > > change will have to get a court order based on irreperable harm and > > show a good faith reason for not being able to object in the time > > period allowed. In the US, this sort of notice plus period for > > objection is standard for quite a few suits and the range of things > > which qualify as "good faith reason" are correspondingly very > > limited. > > It's not clear to me that that's correct. From > (See update), it appears you > need an explicit 95% permission rate to legally relicense and zero > objections. There's no legal basis for those figures (I think they're just examples: Mozilla was happy with 95% but that doesn't mean everyone else doing the same thing would have to gain 95%). The more explicit responses you get, the greater your case for having given proper notice, but there's no case law that I'm aware of on the exact percentages. > So far one objection has already surfaced. This is a more compelling problem: if a contributor actively objects within the notice period, the only real recourse is to rewrite their code (or reason them in to acquiescence). James From kurt at roeckx.be Fri Mar 24 19:21:58 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 24 Mar 2017 20:21:58 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <87k27ewla6.fsf@mid.deneb.enyo.de> References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <87k27ewla6.fsf@mid.deneb.enyo.de> Message-ID: <20170324192157.pa36o2eys5ksrwqh@roeckx.be> On Fri, Mar 24, 2017 at 08:02:25PM +0100, Florian Weimer wrote: > * Quanah Gibson-Mount: > > > Zero people that I know of are saying to switch to the GPL. What is > > being pointed out is that the incompatibility with the current > > OpenSSL license with the GPLv2 has been a major problem. > > The alleged incompatibility of OpenSSL with the GPLv2 has been used to > promote GNUTLS in the past (and to a much lesser extent, a certain > crypto consolidation effort intending to switch everything to NSS). > But GNUTLS has since left the GNU project, and I'm not aware of anyone > on the distribution side still saying that the old OpenSSL license > (particular when used as a dynamically-linked system library) and the > GPLv2 are incompatible. It's just not considered a problem anymore. As far as I know, for Debian it's still a problem that a GPL application links to openssl. A few examples: - We have multiple curl versions, linked to openssl, gnutls, nss. And you then have to build against the correct one for license reasons. - QT (which is LGPL?) does not itself link to libssl but can dynamically load it so that GPL applications can use QT assuming they don't use SSL. - We have asked upstream projects to add an openssl exception to their GPL license. Kurt From James.Bottomley at HansenPartnership.com Fri Mar 24 19:22:14 2017 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 24 Mar 2017 12:22:14 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: <87k27ewla6.fsf@mid.deneb.enyo.de> References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <87k27ewla6.fsf@mid.deneb.enyo.de> Message-ID: <1490383334.2426.42.camel@HansenPartnership.com> On Fri, 2017-03-24 at 20:02 +0100, Florian Weimer wrote: > * Quanah Gibson-Mount: > > > Zero people that I know of are saying to switch to the GPL. What > > is being pointed out is that the incompatibility with the current > > OpenSSL license with the GPLv2 has been a major problem. > > The alleged incompatibility of OpenSSL with the GPLv2 has been used > to promote GNUTLS in the past (and to a much lesser extent, a certain > crypto consolidation effort intending to switch everything to NSS). > But GNUTLS has since left the GNU project, and I'm not aware of > anyone on the distribution side still saying that the old OpenSSL > license (particular when used as a dynamically-linked system library) > and the GPLv2 are incompatible. It's just not considered a problem > anymore. This is my understanding as well. From the GPL side, for both dynamic and static linking of openssl to GPLv2 code, the section 3 system exception applies. James From kurt at roeckx.be Fri Mar 24 19:24:05 2017 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 24 Mar 2017 20:24:05 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <1490383334.2426.42.camel@HansenPartnership.com> References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <87k27ewla6.fsf@mid.deneb.enyo.de> <1490383334.2426.42.camel@HansenPartnership.com> Message-ID: <20170324192405.dcajqneyfqc4v7p3@roeckx.be> On Fri, Mar 24, 2017 at 12:22:14PM -0700, James Bottomley wrote: > > This is my understanding as well. From the GPL side, for both dynamic > and static linking of openssl to GPLv2 code, the section 3 system > exception applies. Not everybody agrees that it applies. Kurt From fw at deneb.enyo.de Fri Mar 24 19:47:23 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 24 Mar 2017 20:47:23 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324192157.pa36o2eys5ksrwqh@roeckx.be> (Kurt Roeckx's message of "Fri, 24 Mar 2017 20:21:58 +0100") References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <87k27ewla6.fsf@mid.deneb.enyo.de> <20170324192157.pa36o2eys5ksrwqh@roeckx.be> Message-ID: <87y3vuv4ms.fsf@mid.deneb.enyo.de> * Kurt Roeckx: > On Fri, Mar 24, 2017 at 08:02:25PM +0100, Florian Weimer wrote: >> * Quanah Gibson-Mount: >> >> > Zero people that I know of are saying to switch to the GPL. What is >> > being pointed out is that the incompatibility with the current >> > OpenSSL license with the GPLv2 has been a major problem. >> >> The alleged incompatibility of OpenSSL with the GPLv2 has been used to >> promote GNUTLS in the past (and to a much lesser extent, a certain >> crypto consolidation effort intending to switch everything to NSS). >> But GNUTLS has since left the GNU project, and I'm not aware of anyone >> on the distribution side still saying that the old OpenSSL license >> (particular when used as a dynamically-linked system library) and the >> GPLv2 are incompatible. It's just not considered a problem anymore. > > As far as I know, for Debian it's still a problem that a GPL > application links to openssl. > > A few examples: > - We have multiple curl versions, linked to openssl, gnutls, nss. > And you then have to build against the correct one for license > reasons. > - QT (which is LGPL?) does not itself link to libssl but can > dynamically load it so that GPL applications can use QT assuming > they don't use SSL. > - We have asked upstream projects to add an openssl exception to > their GPL license. A few examples from Debian for the reverse: - cgit links against libssl1.1 and is GPLv2 - tcpflow has GPLv2 pieces and links against libssl1.1 - many GPLv1 and GPLv2 programs which link against libgcc (which is GPLv3 with an exception, but one that arguably does not make it GPLv2-compatible) I also found a few packages with an OpenSSL exception which have merged GPL code from other sources who may or may not have agreed to the exception. It's probably marginally more productive to continue this discussion on a Debian list (not that I think anymore that this discussion matters). From fw at deneb.enyo.de Fri Mar 24 19:49:10 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Fri, 24 Mar 2017 20:49:10 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: <47B628FBEEE3D3485542B1E6@[192.168.1.19]> (Quanah Gibson-Mount's message of "Fri\, 24 Mar 2017 12\:16\:33 -0700") References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <87k27ewla6.fsf@mid.deneb.enyo.de> <47B628FBEEE3D3485542B1E6@[192.168.1.19]> Message-ID: <87tw6iv4jt.fsf@mid.deneb.enyo.de> * Quanah Gibson-Mount: > --On Friday, March 24, 2017 9:02 PM +0100 Florian Weimer > wrote: > >> * Quanah Gibson-Mount: >> >>> Zero people that I know of are saying to switch to the GPL. What is >>> being pointed out is that the incompatibility with the current >>> OpenSSL license with the GPLv2 has been a major problem. >> >> The alleged incompatibility of OpenSSL with the GPLv2 has been used to >> promote GNUTLS in the past (and to a much lesser extent, a certain >> crypto consolidation effort intending to switch everything to NSS). >> But GNUTLS has since left the GNU project, and I'm not aware of anyone >> on the distribution side still saying that the old OpenSSL license >> (particular when used as a dynamically-linked system library) and the >> GPLv2 are incompatible. It's just not considered a problem anymore. > > So that would imply then that moving to the APL would be a step backward, > since it is explicitly GPLv2 incompatible. ;) It's certainly not ?explicitly? GPL-incompatible. Doesn't the Apache Software Foundation maintain that the intent was it to be compatible? (Which doesn't mean the result of the license design process actually is, but it sheds some light on the ?explicitly? part.) From James.Bottomley at HansenPartnership.com Fri Mar 24 19:49:10 2017 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Fri, 24 Mar 2017 12:49:10 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: <20170324192405.dcajqneyfqc4v7p3@roeckx.be> References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <87k27ewla6.fsf@mid.deneb.enyo.de> <1490383334.2426.42.camel@HansenPartnership.com> <20170324192405.dcajqneyfqc4v7p3@roeckx.be> Message-ID: <1490384950.16999.3.camel@HansenPartnership.com> On Fri, 2017-03-24 at 20:24 +0100, Kurt Roeckx wrote: > On Fri, Mar 24, 2017 at 12:22:14PM -0700, James Bottomley wrote: > > > > This is my understanding as well. From the GPL side, for both > > dynamic > > and static linking of openssl to GPLv2 code, the section 3 system > > exception applies. > > Not everybody agrees that it applies. debian-legal is OK with shipping other libraries which require the system exception to link with GPLv2 code, so I don't find their position to be entirely self consistent. Regardless, if you move to Apache-2.0 you'll still use the system exception to link with GPLv2 code, but it will be much more acceptable. James From quanah at symas.com Fri Mar 24 21:13:41 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Fri, 24 Mar 2017 14:13:41 -0700 Subject: [openssl-dev] License change agreement In-Reply-To: References: <20170323144149.GA14513@openssl.org> <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <87k27ewla6.fsf@mid.deneb.enyo.de> <1490383334.2426.42.camel@HansenPartnership.com> <20170324192405.dcajqneyfqc4v7p3@roeckx.be> <1490384950.16999.3.camel@HansenPartnership.com> Message-ID: <00AFF948C9BAE0DAC4CCE7BB@[192.168.1.19]> --On Friday, March 24, 2017 1:49 PM -0700 James Bottomley wrote: > On Fri, 2017-03-24 at 20:24 +0100, Kurt Roeckx wrote: >> On Fri, Mar 24, 2017 at 12:22:14PM -0700, James Bottomley wrote: >> > >> > This is my understanding as well. From the GPL side, for both >> > dynamic >> > and static linking of openssl to GPLv2 code, the section 3 system >> > exception applies. >> >> Not everybody agrees that it applies. > > debian-legal is OK with shipping other libraries which require the > system exception to link with GPLv2 code, so I don't find their > position to be entirely self consistent. Regardless, if you move to > Apache-2.0 you'll still use the system exception to link with GPLv2 > code, but it will be much more acceptable. If you mean , I would note that not all software includes such an exception. I ran into that a few times in the past, and had to work with the authors to adjust their license (in one case) and move to alternatives for other cases. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From dirkx at webweaving.org Fri Mar 24 21:35:20 2017 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Fri, 24 Mar 2017 22:35:20 +0100 Subject: [openssl-dev] License change agreement In-Reply-To: References: <2C8B7B7769C9A74C27D90D8E@192.168.1.19> <7143B41A-DF2F-4914-B4B6-91D5F782321F@ll.mit.edu> <20170324064858.GN70789@colo.drijf.net> <20170324072149.GC3856@suse.de> <20170324073602.GO70789@colo.drijf.net> <20170324084015.uan4qzvk6yia6jxs@roeckx.be> <20170324090653.GP70789@colo.drijf.net> <1490380219.2426.15.camel@HansenPartnership.com> Message-ID: On 24 Mar 2017, at 20:03, Quanah Gibson-Mount wrote: > --On Friday, March 24, 2017 12:30 PM -0700 James Bottomley wrote: > > >>> Probably illegal and definitely immoral, in my opinion. Copyright law >>> exists to protect authors from these kind of practises. >> >> I think you misunderstand the legal situation. Provided notice is >> sufficiently widely distributed and a reasonable period is allowed for >> objections it will become an estoppel issue after the licence is >> changed, which means anyone trying to object after the fact of the >> change will have to get a court order based on irreperable harm and >> show a good faith reason for not being able to object in the time >> period allowed. In the US, this sort of notice plus period for >> objection is standard for quite a few suits and the range of things >> which qualify as "good faith reason" are correspondingly very limited. > > It's not clear to me that that's correct. From (See update), it appears you need an explicit 95% permission rate to legally relicense and zero objections. So far one objection has already surfaced. I have a hard time imagining there to be any 'legal' basis for those numbers or that stark approach; the the US, UK or Europe. Even for well defined processes in publishing like for orphaned works. In the real world these sort of things happen often - and are never quite that black and white. Open source foundations often have to take certain risks (and document these) when accepting contributions. People may have died, businesses may have gone under, (ex) spouses or decedents may have rights that are naught impossible to reconstruct, contributors may be under court orders or the legally appointed owner after a bankruptcy case may have rights, etc, etc. So in the end it you need to be rational about those things - "veto"s and "not legal" are rarely, if ever, applicable. We learned that in the past 30 years. And even when things are fairly black and white or ironclad - the result can still befuddle us. Of particular importance is also *this* case is that the shift is relatively modest - from the current license to the ASL. Rather than, say, to the GPL, Affero or a midway house like the MPL. That, continuing honouring past & present contributors and the 0 $ fee/license costs, curtails the irreparable harm harm sharply. Dw From clopez at igalia.com Sat Mar 25 15:19:51 2017 From: clopez at igalia.com (Carlos Alberto Lopez Perez) Date: Sat, 25 Mar 2017 16:19:51 +0100 Subject: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible In-Reply-To: References: Message-ID: <76e8948b-b4f2-1e30-1e88-f35093a1582e@igalia.com> On 23/03/17 21:04, Brian Smith wrote: > Hi, > > I'm one of the people that received the email asking for permission to > relicense code to the new license, Apache 2.0. Same here. > 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 the GPL3 license, many people also object to the > GPL3 license for important (to them) reasons. Therefore, I think it is > important for the OpenSSL license to be compatible with GPL2 too. > > In the past, I created a library licensed under Apache 2.0, > mozilla::pkix. However, Red Hat and Mozilla requested that I > additionally license it under the GPLv2 so they could use it in > GPLv2-licensed contexts, and I did so. > > Similarly, LLVM is working on moving to the Apache 2.0 license and > they ran into similar problems. They also made the effort to > explicitly grant the right to use the relicensed code under the GPLv2. > See [1] for details. > > I think it is important that OpenSSL do something similar to > explicitly allow using OpenSSL code under the GPLv2 before any > relicensing takes place. > > Thanks for your consideration. > > [1] http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html > > Cheers, > Brian > I explicitly support this request. Please, in the final OpenSSL license text add the paragraph linked in the above LLVM mailing list as an exception to the Apache license. We should make sure using OpenSSL in GPLv2-only projects its possible without any trouble or concern for developers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 883 bytes Desc: OpenPGP digital signature URL: From rsalz at akamai.com Sat Mar 25 16:10:16 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 25 Mar 2017 16:10:16 +0000 Subject: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible In-Reply-To: <76e8948b-b4f2-1e30-1e88-f35093a1582e@igalia.com> References: <76e8948b-b4f2-1e30-1e88-f35093a1582e@igalia.com> Message-ID: > Please, in the final OpenSSL license text add the paragraph linked in the > above LLVM mailing list as an exception to the Apache license. > > We should make sure using OpenSSL in GPLv2-only projects its possible > without any trouble or concern for developers. The problem is that if it is distributed under the GPLv2 there is no patent protection, and that is important to us. Sorry, we can't do that. Options include: GPL authors adding an exception, using something with a compatible license, treating OpenSSL as a system library, or deciding that dynamically linking is sufficient. From clopez at igalia.com Sat Mar 25 18:47:23 2017 From: clopez at igalia.com (Carlos Alberto Lopez Perez) Date: Sat, 25 Mar 2017 19:47:23 +0100 Subject: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible In-Reply-To: References: <76e8948b-b4f2-1e30-1e88-f35093a1582e@igalia.com> Message-ID: <987642be-fc0c-4f12-8de5-46eb82e8b3d3@igalia.com> On 25/03/17 17:10, Salz, Rich via openssl-dev wrote: > >> Please, in the final OpenSSL license text add the paragraph linked in the >> above LLVM mailing list as an exception to the Apache license. >> >> We should make sure using OpenSSL in GPLv2-only projects its possible >> without any trouble or concern for developers. > > The problem is that if it is distributed under the GPLv2 there is no patent protection, and that is important to us. > > Sorry, we can't do that. > > Options include: GPL authors adding an exception, using something with a compatible license, treating OpenSSL as a system library, or deciding that dynamically linking is sufficient. > Unfortunately, dynamically linking is not a solution. My understanding is that the GPLv2 considers any library used by the GPLv2 program (it doesn't make a difference between dynamic or static linking) part of the same whole covered work. [1] Therefore the respective licenses of each one of this libraries, can't impose any further restrictions on the rights granted by the GPLv2 itself. And the obligations that the Apache 2.0 license imposes over patent related rights, are considered a further restriction in this context. [1] https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 883 bytes Desc: OpenPGP digital signature URL: From James.Bottomley at HansenPartnership.com Sat Mar 25 20:21:28 2017 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sat, 25 Mar 2017 13:21:28 -0700 Subject: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible In-Reply-To: References: <76e8948b-b4f2-1e30-1e88-f35093a1582e@igalia.com> Message-ID: <1490473288.2236.38.camel@HansenPartnership.com> On Sat, 2017-03-25 at 16:10 +0000, Salz, Rich via openssl-dev wrote: > > > Please, in the final OpenSSL license text add the paragraph linked > > in the above LLVM mailing list as an exception to the Apache > > license. > > > > We should make sure using OpenSSL in GPLv2-only projects its > > possible without any trouble or concern for developers. > > The problem is that if it is distributed under the GPLv2 there is no > patent protection, and that is important to us. I've already told you once that this is a factually incorrect statement because (L)GPLv2 contains an implicit patent licence: https://mta.openssl.org/pipermail/openssl-dev/2017-March/009208.html but you can have it from a more authoritative source if you like: https://copyleft.org/guide/comprehensive-gpl-guidech7.html Additionally, since under Apache-2.0 the explicit patent grants are captured on contribution, they can't be lost again by the act of using the LLVM exception to distribute a portion of the code under another licence. James From fw at deneb.enyo.de Sat Mar 25 20:48:08 2017 From: fw at deneb.enyo.de (Florian Weimer) Date: Sat, 25 Mar 2017 21:48:08 +0100 Subject: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible In-Reply-To: <1490473288.2236.38.camel@HansenPartnership.com> (James Bottomley's message of "Sat, 25 Mar 2017 13:21:28 -0700") References: <76e8948b-b4f2-1e30-1e88-f35093a1582e@igalia.com> <1490473288.2236.38.camel@HansenPartnership.com> Message-ID: <87vaqxjd6f.fsf@mid.deneb.enyo.de> * James Bottomley: > On Sat, 2017-03-25 at 16:10 +0000, Salz, Rich via openssl-dev wrote: >> >> > Please, in the final OpenSSL license text add the paragraph linked >> > in the above LLVM mailing list as an exception to the Apache >> > license. >> > >> > We should make sure using OpenSSL in GPLv2-only projects its >> > possible without any trouble or concern for developers. >> >> The problem is that if it is distributed under the GPLv2 there is no >> patent protection, and that is important to us. > > I've already told you once that this is a factually incorrect statement > because (L)GPLv2 contains an implicit patent licence: I think the fact that Richard rejects dual licensing indicates that it's not the lack of a licence that concerns him, but something else. He calls it ?patent protection?; I assume he refers to the weak mutually assured destruction clause in the Apache license (the ?If You institute patent litigation against any entity? part). I don't think the GPL, version 2, contains anything remote close to *that*, implied or otherwise. From rsalz at akamai.com Sat Mar 25 21:22:35 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 25 Mar 2017 21:22:35 +0000 Subject: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible In-Reply-To: <1490473288.2236.38.camel@HansenPartnership.com> References: <76e8948b-b4f2-1e30-1e88-f35093a1582e@igalia.com> <1490473288.2236.38.camel@HansenPartnership.com> Message-ID: <1fe00211d76948908b2d0bace760c54a@usma1ex-dag1mb1.msg.corp.akamai.com> > > The problem is that if it is distributed under the GPLv2 there is no > > patent protection, and that is important to us. > > I've already told you once that this is a factually incorrect statement because > (L)GPLv2 contains an implicit patent licence: By patent protection, I mean "you lose your rights to use this if you sue" That seems to be typical use of patent protection, when talking about FOSS licenses. Sorry if I was too casual in my wording. From tytso at mit.edu Sat Mar 25 21:16:25 2017 From: tytso at mit.edu (Theodore Ts'o) Date: Sat, 25 Mar 2017 17:16:25 -0400 Subject: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible In-Reply-To: <987642be-fc0c-4f12-8de5-46eb82e8b3d3@igalia.com> References: <76e8948b-b4f2-1e30-1e88-f35093a1582e@igalia.com> <987642be-fc0c-4f12-8de5-46eb82e8b3d3@igalia.com> Message-ID: <20170325211625.kr5tlygb7iqcfyqr@thunk.org> On Sat, Mar 25, 2017 at 07:47:23PM +0100, Carlos Alberto Lopez Perez wrote: > Unfortunately, dynamically linking is not a solution. > > My understanding is that the GPLv2 considers any library used by the > GPLv2 program (it doesn't make a difference between dynamic or static > linking) part of the same whole covered work. [1] > Therefore the respective licenses of each one of this libraries, can't > impose any further restrictions on the rights granted by the GPLv2 itself. > And the obligations that the Apache 2.0 license imposes over patent > related rights, are considered a further restriction in this context. It's complicated. It's fair to say that the FSF adopts a copyright maximalist position, and by their interpretation, the two licenses are incompatible, and it doesn't matter whether the two pieces of code are linked staticaly, dynamically, or (according to at least one very extereme apologist) one calls the other over an RPC call. Not everyone agrees with their legal analysis. May I suggest that we not play amateur lawyer on the mailing list, and try to settle this here? Each Linux distribution can make its own decision, which will be based on its legal advice, the local laws and legal precedents in which they operate, whether the code is owned by the an extremely litigious entity, etc. And indeed, different Linux distributions have already come to different conclusions with respect to various license compatibility issues. (Examples: dynamically linking GPL programs with OpenSSL libraries under the old license, distributing ZFS modules for Linux, etc.) We don't expect lawyers to debug edge cases in a compiler's code generation. Programmers shouldn't try to parse edge cases in the law, or try to use a soldering iron, unless they have explicit training and expertise to do so. :-) - Ted From James.Bottomley at HansenPartnership.com Sat Mar 25 23:55:48 2017 From: James.Bottomley at HansenPartnership.com (James Bottomley) Date: Sat, 25 Mar 2017 16:55:48 -0700 Subject: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible In-Reply-To: <87vaqxjd6f.fsf@mid.deneb.enyo.de> References: <76e8948b-b4f2-1e30-1e88-f35093a1582e@igalia.com> <1490473288.2236.38.camel@HansenPartnership.com> <87vaqxjd6f.fsf@mid.deneb.enyo.de> Message-ID: <1490486148.2236.57.camel@HansenPartnership.com> On Sat, 2017-03-25 at 21:48 +0100, Florian Weimer wrote: > * James Bottomley: > > > On Sat, 2017-03-25 at 16:10 +0000, Salz, Rich via openssl-dev > > wrote: > > > > > > > Please, in the final OpenSSL license text add the paragraph > > > > linked in the above LLVM mailing list as an exception to the > > > > Apache license. > > > > > > > > We should make sure using OpenSSL in GPLv2-only projects its > > > > possible without any trouble or concern for developers. > > > > > > The problem is that if it is distributed under the GPLv2 there is > > > no patent protection, and that is important to us. > > > > I've already told you once that this is a factually incorrect > > statement because (L)GPLv2 contains an implicit patent licence: > > I think the fact that Richard rejects dual licensing indicates that > it's not the lack of a licence that concerns him, but something else. > He calls it ?patent protection?; I assume he refers to the weak > mutually assured destruction clause in the Apache license (the ?If > You institute patent litigation against any entity? part). Oh, OK ... and Rich confirms that below. So I agree, GPLv2 doesn't have a patent retaliation clause. > I don't think the GPL, version 2, contains anything remote close to > *that*, implied or otherwise. No; the closest is clause 7 which basically shuts down distribution for everyone in the event of a successful patent assertion. You could also characterise that as a mutually assured destruction clause. However both of these only work if the asserting entity needs the rights that are blocked. Unfortunately the most problematic assertions nowadays are done by troll entities who don't need any rights from us. James From quanah at symas.com Sun Mar 26 20:36:31 2017 From: quanah at symas.com (Quanah Gibson-Mount) Date: Sun, 26 Mar 2017 13:36:31 -0700 Subject: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible In-Reply-To: References: <76e8948b-b4f2-1e30-1e88-f35093a1582e@igalia.com> <987642be-fc0c-4f12-8de5-46eb82e8b3d3@igalia.com> <20170325211625.kr5tlygb7iqcfyqr@thunk.org> Message-ID: <6674F05227A2E09C1F9C8698@[192.168.1.19]> --On Saturday, March 25, 2017 6:16 PM -0400 Theodore Ts'o wrote: > And indeed, different Linux distributions have already come to > different conclusions with respect to various license compatibility > issues. (Examples: dynamically linking GPL programs with OpenSSL > libraries under the old license, distributing ZFS modules for Linux, > etc.) This makes the completely unfounded assumption that only distributions build and ship OpenSSL. Many companies build and use products based on top of OpenSSL, which they distribute, that is entirely and appropriately separate from whatever OS their application may be running on top of. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: From raja.ashok at huawei.com Mon Mar 27 08:25:16 2017 From: raja.ashok at huawei.com (Raja ashok) Date: Mon, 27 Mar 2017 08:25:16 +0000 Subject: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing Message-ID: Hi, I feel there is a check missing in ssl3_write_bytes, in case of handling write failure. Consider SSL_write is called with 20000 bytes buffer, then internally in ssl3_write_bytes we try to send it as two record (16384 and 3616). If TCP send failed for the second record then we store the states internally (wnum, wpend_tot and wpend_buf) and return back the result. Later application has to call SSL_write with same buffer, if it calls with different buffer of length 100 byte then we fail that in ssl3_write_bytes using the check (len < tot). But consider application calls with buffer of size 18000 bytes and SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is enabled. Then (len < tot) will not succeed as tot is 16384. Then it will call ssl3_write_pending to send the remaining 3616 record. If it succeeds we are incrementing tot, (tot += i). Now tot will have 20000. Later there is a check (tot == len), this will not succeed. Then directly we are doing n = (len - tot), this will overflow and store a value close to 2^32 in n. Then it will cause out of bound access to the application buffer "buf". I hope we should have one more check (len < (tot + s->s3->wpend_tot)) before calling ssl3_write_pending. if ((len < tot) || (len < (tot + s->s3->wpend_tot))){ SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH); return (-1); } Note : I am referring 1.0.2k version of OpenSSL. Regards, Ashok ________________________________ [Company_logo] Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ________________________________ ???????????????????????????????????????? ???????????????????????????????????????? ??????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6737 bytes Desc: image001.jpg URL: From darshanmody at avaya.com Mon Mar 27 08:40:30 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Mon, 27 Mar 2017 08:40:30 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A107853@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A1077F2@AZ-FFEXMB03.global.avaya.com> <3fab20f8-b60c-6edc-7922-e184000c987c@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10781E@AZ-FFEXMB03.global.avaya.com> <20170323.150038.1594136336870474788.levitte@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A107853@AZ-FFEXMB03.global.avaya.com> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A108EFC@AZ-FFEXMB03.global.avaya.com> Matt, Richard, I have not created any patch. Instead I am using s_server app provided from Openssl. Below is the server side command run openssl s_server -accept -key -cert -CAfile -verify On the client side I am running script below #/bin/sh while [ 1 ] do openssl s_client -connect : -cert -key &>/dev/null done Running the client once and printing the results showed the cipher selected was ECDHE cipher. I believe there is inherent leak in the ECDHE side of openssl. I find that the server started leaking was leaking. Check the Resident memory and the CPU. Resident memory increases after every 3 second. When I had stopped the client traffic the resident memory did not increase however it did not returned back to what it was earlier. Hope this will help to reproduce the issue. top - 10:16:37 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 0.6%us, 0.1%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 3924288k total, 3757716k used, 166572k free, 78200k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219736k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 39908 3528 2740 S 0.0 0.1 0:00.00 openssl top - 10:16:40 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie Cpu(s): 1.6%us, 0.9%sy, 0.0%ni, 97.4%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st Mem: 3924288k total, 3757856k used, 166432k free, 78208k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 39908 3532 2740 R 4.3 0.1 0:00.13 openssl top - 10:16:43 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 2.6%us, 0.8%sy, 0.1%ni, 96.2%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 3924288k total, 3757980k used, 166308k free, 78232k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 39908 3544 2740 S 7.0 0.1 0:00.34 openssl top - 10:16:46 up 46 days, 1:30, 2 users, load average: 0.03, 0.06, 0.08 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 2.1%us, 1.1%sy, 0.0%ni, 96.5%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 3924288k total, 3757964k used, 166324k free, 78248k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219732k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 39908 3560 2740 S 6.7 0.1 0:00.54 openssl top - 10:16:49 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 2.7%us, 1.1%sy, 0.0%ni, 96.0%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st Mem: 3924288k total, 3758212k used, 166076k free, 78264k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 39908 3572 2740 S 8.0 0.1 0:00.78 openssl top - 10:16:52 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.2%us, 1.2%sy, 0.0%ni, 94.8%id, 0.1%wa, 0.0%hi, 0.6%si, 0.0%st Mem: 3924288k total, 3758212k used, 166076k free, 78288k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219732k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 39908 3592 2740 S 11.0 0.1 0:01.11 openssl top - 10:16:55 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.3%us, 1.3%sy, 0.1%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st Mem: 3924288k total, 3758584k used, 165704k free, 78288k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 39908 3608 2740 S 11.3 0.1 0:01.45 openssl top - 10:16:58 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.3%us, 1.6%sy, 0.0%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st Mem: 3924288k total, 3758864k used, 165424k free, 78296k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 39908 3628 2740 S 11.3 0.1 0:01.79 openssl top - 10:17:01 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.4%us, 1.5%sy, 0.0%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st Mem: 3924288k total, 3758956k used, 165332k free, 78312k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219740k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 40016 3648 2740 S 10.7 0.1 0:02.11 openssl top - 10:17:04 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.9%us, 1.9%sy, 0.0%ni, 91.9%id, 1.6%wa, 0.0%hi, 0.7%si, 0.0%st Mem: 3924288k total, 3759708k used, 164580k free, 78328k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219916k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 40016 3668 2740 S 11.0 0.1 0:02.44 openssl top - 10:17:07 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie Cpu(s): 3.4%us, 1.2%sy, 0.1%ni, 93.8%id, 0.0%wa, 0.0%hi, 1.4%si, 0.0%st Mem: 3924288k total, 3759336k used, 164952k free, 78360k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219900k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 40016 3688 2740 R 10.7 0.1 0:02.76 openssl top - 10:17:10 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.2%us, 1.6%sy, 0.0%ni, 94.2%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st Mem: 3924288k total, 3758584k used, 165704k free, 78360k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219916k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 40016 3708 2740 S 11.3 0.1 0:03.10 openssl top - 10:17:13 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.6%us, 1.1%sy, 0.0%ni, 94.5%id, 0.0%wa, 0.0%hi, 0.8%si, 0.0%st Mem: 3924288k total, 3758476k used, 165812k free, 78376k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219920k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 40016 3728 2740 S 10.7 0.1 0:03.42 openssl top - 10:17:16 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.8%us, 1.3%sy, 0.0%ni, 93.3%id, 0.0%wa, 0.0%hi, 1.7%si, 0.0%st Mem: 3924288k total, 3759824k used, 164464k free, 78384k buffers Swap: 8388604k total, 999556k used, 7389048k free, 219920k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 40124 3748 2740 S 11.3 0.1 0:03.76 openssl --------------- top - 10:23:10 up 46 days, 1:36, 2 users, load average: 0.03, 0.05, 0.06 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.6%us, 1.3%sy, 0.1%ni, 94.4%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st Mem: 3924288k total, 3756048k used, 168240k free, 75888k buffers Swap: 8388604k total, 998972k used, 7389632k free, 216576k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 42392 6048 2740 S 10.7 0.2 0:41.95 openssl top - 10:23:13 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.2%us, 1.3%sy, 0.0%ni, 94.8%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st Mem: 3924288k total, 3756064k used, 168224k free, 75904k buffers Swap: 8388604k total, 998972k used, 7389632k free, 216572k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 42392 6068 2740 S 10.7 0.2 0:42.27 openssl top - 10:23:16 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie Cpu(s): 3.2%us, 1.3%sy, 0.1%ni, 94.9%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st Mem: 3924288k total, 3756188k used, 168100k free, 75912k buffers Swap: 8388604k total, 998972k used, 7389632k free, 216572k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 42392 6088 2740 R 11.0 0.2 0:42.60 openssl top - 10:23:19 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 3.1%us, 1.2%sy, 1.6%ni, 93.5%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st Mem: 3924288k total, 3756528k used, 167760k free, 75920k buffers Swap: 8388604k total, 998972k used, 7389632k free, 216584k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 42392 6108 2740 S 10.7 0.2 0:42.92 openssl top - 10:23:22 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie Cpu(s): 11.1%us, 4.6%sy, 20.2%ni, 63.6%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st Mem: 3924288k total, 3756924k used, 167364k free, 75952k buffers Swap: 8388604k total, 998972k used, 7389632k free, 216600k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27303 root 20 0 42500 6124 2740 S 10.3 0.2 0:43.23 openssl Thanks Darshan -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Mody, Darshan (Darshan) Sent: Thursday, March 23, 2017 7:40 PM To: openssl-dev at openssl.org Cc: Bahr, William G (Bill) Subject: Re: [openssl-dev] Memory leak in application when we use ECDH 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-bounces at openssl.org] On Behalf Of Richard Levitte Sent: Thursday, March 23, 2017 7:31 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH 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 together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out. Cheers, Richard In message <25D2EC755404B4409F263AC6D050FEBB2A10781E at AZ-FFEXMB03.global.avaya.com> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" said: darshanmody> Matt, darshanmody> darshanmody> Below is the scenario. darshanmody> darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain. darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app. darshanmody> 3. Connect client with certificates that server does not trust. darshanmody> 4. The connections from client to server fails darshanmody> darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved. darshanmody> darshanmody> Hope this helps darshanmody> darshanmody> Thanks darshanmody> Darshan darshanmody> darshanmody> -----Original Message----- darshanmody> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] darshanmody> On Behalf Of Matt Caswell darshanmody> Sent: Thursday, March 23, 2017 6:55 PM darshanmody> To: openssl-dev at openssl.org darshanmody> Subject: Re: [openssl-dev] Memory leak in application when darshanmody> we use ECDH darshanmody> darshanmody> darshanmody> darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote: darshanmody> > Can you further elaborate? darshanmody> > darshanmody> > What we did is to create a TLS connection and with darshanmody> > invalid certificates from the client and server on darshanmody> > verification would reject the certificate. The cipher darshanmody> > negotiated was ECDHE cipher between client and server. darshanmody> > darshanmody> > This was done with load (multiple while 1 script trying darshanmody> > to connect to server using invalid certificates and in darshanmody> > course of time the memory was increasing). darshanmody> darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. darshanmody> darshanmody> Matt darshanmody> darshanmody> darshanmody> > darshanmody> > Thanks Darshan darshanmody> > darshanmody> > -----Original Message----- From: openssl-dev darshanmody> > [mailto:openssl-dev-bounces at openssl.org] On Behalf Of darshanmody> > Matt Caswell darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: darshanmody> > openssl-dev at openssl.org darshanmody> > Subject: Re: [openssl-dev] Memory leak in application darshanmody> > when we use ECDH darshanmody> > darshanmody> > darshanmody> > darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: darshanmody> >> Matt, darshanmody> >> darshanmody> >> Even after accounting for the EC_KEY we still observe some leak. darshanmody> >> The leak started after we started using supporting EC darshanmody> >> with callback SSL_set_tmp_ecdh_callback(). darshanmody> >> darshanmody> >> The core dump shows the string data of the far-end certificates. darshanmody> >> I cannot pin point the code in openssl with this regard. darshanmody> > darshanmody> > Are you able to create a simple reproducer demonstrating darshanmody> > the problem with the callback? darshanmody> > darshanmody> > Matt darshanmody> > darshanmody> -- darshanmody> openssl-dev mailing list darshanmody> To unsubscribe: darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8 darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK darshanmody> fQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf darshanmody> _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e= darshanmody> -- darshanmody> openssl-dev mailing list darshanmody> To unsubscribe: darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8 darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK darshanmody> fQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q darshanmody> 92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= darshanmody> -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=aM8Nc6bSJzLs-HdERDikYMeQK6uUqvjYvWnfqtvREM4&s=5DECvTKmFHf9urfCwMDaDnk14k9fM_XDkpl9X5r5aJA&e= From levitte at openssl.org Mon Mar 27 08:50:29 2017 From: levitte at openssl.org (Richard Levitte) Date: Mon, 27 Mar 2017 10:50:29 +0200 (CEST) Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A108EFC@AZ-FFEXMB03.global.avaya.com> References: <20170323.150038.1594136336870474788.levitte@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A107853@AZ-FFEXMB03.global.avaya.com> <25D2EC755404B4409F263AC6D050FEBB2A108EFC@AZ-FFEXMB03.global.avaya.com> Message-ID: <20170327.105029.1752989122182278415.levitte@openssl.org> Are you confident this is the same leak that you have experienced? Your original complaint was about keys created with the callback that's added with SSL_set_tmp_ecdh_callback(), and I have to point out that s_server doesn't provide such a callback. In fact, SSL_set_tmp_ecdh_callback() isn't called anywhere in the OpenSSL source. That doesn't mean you haven't found the same leak, if there is a leak (I'm not going to rule out some other explanation), it might simply clarify that targeting on the EC_KEY returned from the callback might make us blind for something else that's related. Cheers, Richard In message <25D2EC755404B4409F263AC6D050FEBB2A108EFC at AZ-FFEXMB03.global.avaya.com> on Mon, 27 Mar 2017 08:40:30 +0000, "Mody, Darshan (Darshan)" said: darshanmody> Matt, Richard, darshanmody> darshanmody> I have not created any patch. Instead I am using s_server app provided from Openssl. Below is the server side command run darshanmody> darshanmody> openssl s_server -accept -key -cert -CAfile -verify darshanmody> darshanmody> On the client side I am running script below darshanmody> darshanmody> #/bin/sh darshanmody> darshanmody> while [ 1 ] darshanmody> do darshanmody> openssl s_client -connect : -cert -key &>/dev/null darshanmody> done darshanmody> darshanmody> Running the client once and printing the results showed the cipher selected was ECDHE cipher. I believe there is inherent leak in the ECDHE side of openssl. darshanmody> darshanmody> I find that the server started leaking was leaking. Check the Resident memory and the CPU. Resident memory increases after every 3 second. When I had stopped the client traffic the resident memory did not increase however it did not returned back to what it was earlier. Hope this will help to reproduce the issue. darshanmody> darshanmody> top - 10:16:37 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 0.6%us, 0.1%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st darshanmody> Mem: 3924288k total, 3757716k used, 166572k free, 78200k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219736k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 39908 3528 2740 S 0.0 0.1 0:00.00 openssl darshanmody> darshanmody> darshanmody> top - 10:16:40 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 darshanmody> Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 1.6%us, 0.9%sy, 0.0%ni, 97.4%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st darshanmody> Mem: 3924288k total, 3757856k used, 166432k free, 78208k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 39908 3532 2740 R 4.3 0.1 0:00.13 openssl darshanmody> darshanmody> darshanmody> top - 10:16:43 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 2.6%us, 0.8%sy, 0.1%ni, 96.2%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st darshanmody> Mem: 3924288k total, 3757980k used, 166308k free, 78232k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 39908 3544 2740 S 7.0 0.1 0:00.34 openssl darshanmody> darshanmody> darshanmody> top - 10:16:46 up 46 days, 1:30, 2 users, load average: 0.03, 0.06, 0.08 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 2.1%us, 1.1%sy, 0.0%ni, 96.5%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st darshanmody> Mem: 3924288k total, 3757964k used, 166324k free, 78248k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219732k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 39908 3560 2740 S 6.7 0.1 0:00.54 openssl darshanmody> darshanmody> darshanmody> top - 10:16:49 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 2.7%us, 1.1%sy, 0.0%ni, 96.0%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st darshanmody> Mem: 3924288k total, 3758212k used, 166076k free, 78264k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 39908 3572 2740 S 8.0 0.1 0:00.78 openssl darshanmody> darshanmody> darshanmody> top - 10:16:52 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.2%us, 1.2%sy, 0.0%ni, 94.8%id, 0.1%wa, 0.0%hi, 0.6%si, 0.0%st darshanmody> Mem: 3924288k total, 3758212k used, 166076k free, 78288k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219732k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 39908 3592 2740 S 11.0 0.1 0:01.11 openssl darshanmody> darshanmody> darshanmody> top - 10:16:55 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.3%us, 1.3%sy, 0.1%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st darshanmody> Mem: 3924288k total, 3758584k used, 165704k free, 78288k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 39908 3608 2740 S 11.3 0.1 0:01.45 openssl darshanmody> darshanmody> darshanmody> top - 10:16:58 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.3%us, 1.6%sy, 0.0%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st darshanmody> Mem: 3924288k total, 3758864k used, 165424k free, 78296k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 39908 3628 2740 S 11.3 0.1 0:01.79 openssl darshanmody> darshanmody> darshanmody> top - 10:17:01 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.4%us, 1.5%sy, 0.0%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st darshanmody> Mem: 3924288k total, 3758956k used, 165332k free, 78312k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219740k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 40016 3648 2740 S 10.7 0.1 0:02.11 openssl darshanmody> darshanmody> darshanmody> top - 10:17:04 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.9%us, 1.9%sy, 0.0%ni, 91.9%id, 1.6%wa, 0.0%hi, 0.7%si, 0.0%st darshanmody> Mem: 3924288k total, 3759708k used, 164580k free, 78328k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219916k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 40016 3668 2740 S 11.0 0.1 0:02.44 openssl darshanmody> darshanmody> darshanmody> top - 10:17:07 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 darshanmody> Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.4%us, 1.2%sy, 0.1%ni, 93.8%id, 0.0%wa, 0.0%hi, 1.4%si, 0.0%st darshanmody> Mem: 3924288k total, 3759336k used, 164952k free, 78360k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219900k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 40016 3688 2740 R 10.7 0.1 0:02.76 openssl darshanmody> darshanmody> darshanmody> top - 10:17:10 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.2%us, 1.6%sy, 0.0%ni, 94.2%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st darshanmody> Mem: 3924288k total, 3758584k used, 165704k free, 78360k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219916k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 40016 3708 2740 S 11.3 0.1 0:03.10 openssl darshanmody> darshanmody> darshanmody> top - 10:17:13 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.6%us, 1.1%sy, 0.0%ni, 94.5%id, 0.0%wa, 0.0%hi, 0.8%si, 0.0%st darshanmody> Mem: 3924288k total, 3758476k used, 165812k free, 78376k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219920k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 40016 3728 2740 S 10.7 0.1 0:03.42 openssl darshanmody> darshanmody> darshanmody> top - 10:17:16 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.8%us, 1.3%sy, 0.0%ni, 93.3%id, 0.0%wa, 0.0%hi, 1.7%si, 0.0%st darshanmody> Mem: 3924288k total, 3759824k used, 164464k free, 78384k buffers darshanmody> Swap: 8388604k total, 999556k used, 7389048k free, 219920k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 40124 3748 2740 S 11.3 0.1 0:03.76 openssl darshanmody> darshanmody> --------------- darshanmody> darshanmody> top - 10:23:10 up 46 days, 1:36, 2 users, load average: 0.03, 0.05, 0.06 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.6%us, 1.3%sy, 0.1%ni, 94.4%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st darshanmody> Mem: 3924288k total, 3756048k used, 168240k free, 75888k buffers darshanmody> Swap: 8388604k total, 998972k used, 7389632k free, 216576k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 42392 6048 2740 S 10.7 0.2 0:41.95 openssl darshanmody> darshanmody> darshanmody> top - 10:23:13 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.2%us, 1.3%sy, 0.0%ni, 94.8%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st darshanmody> Mem: 3924288k total, 3756064k used, 168224k free, 75904k buffers darshanmody> Swap: 8388604k total, 998972k used, 7389632k free, 216572k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 42392 6068 2740 S 10.7 0.2 0:42.27 openssl darshanmody> darshanmody> darshanmody> top - 10:23:16 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 darshanmody> Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.2%us, 1.3%sy, 0.1%ni, 94.9%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st darshanmody> Mem: 3924288k total, 3756188k used, 168100k free, 75912k buffers darshanmody> Swap: 8388604k total, 998972k used, 7389632k free, 216572k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 42392 6088 2740 R 11.0 0.2 0:42.60 openssl darshanmody> darshanmody> darshanmody> top - 10:23:19 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 3.1%us, 1.2%sy, 1.6%ni, 93.5%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st darshanmody> Mem: 3924288k total, 3756528k used, 167760k free, 75920k buffers darshanmody> Swap: 8388604k total, 998972k used, 7389632k free, 216584k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 42392 6108 2740 S 10.7 0.2 0:42.92 openssl darshanmody> darshanmody> darshanmody> top - 10:23:22 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 darshanmody> Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie darshanmody> Cpu(s): 11.1%us, 4.6%sy, 20.2%ni, 63.6%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st darshanmody> Mem: 3924288k total, 3756924k used, 167364k free, 75952k buffers darshanmody> Swap: 8388604k total, 998972k used, 7389632k free, 216600k cached darshanmody> darshanmody> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND darshanmody> 27303 root 20 0 42500 6124 2740 S 10.3 0.2 0:43.23 openssl darshanmody> darshanmody> Thanks darshanmody> Darshan darshanmody> darshanmody> -----Original Message----- darshanmody> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Mody, Darshan (Darshan) darshanmody> Sent: Thursday, March 23, 2017 7:40 PM darshanmody> To: openssl-dev at openssl.org darshanmody> Cc: Bahr, William G (Bill) darshanmody> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH darshanmody> darshanmody> Thanks Richard and Matt, darshanmody> darshanmody> I will patch it and send the patch. It will take me couple of days. darshanmody> darshanmody> Regards darshanmody> Darshan darshanmody> darshanmody> -----Original Message----- darshanmody> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Richard Levitte darshanmody> Sent: Thursday, March 23, 2017 7:31 PM darshanmody> To: openssl-dev at openssl.org darshanmody> Subject: Re: [openssl-dev] Memory leak in application when we use ECDH darshanmody> darshanmody> I think that Matt is asking for example code that exhibits this leak. darshanmody> You could patch apps/s_server.c with your callback, or ssl/ssltest.c, and give us that patch. darshanmody> darshanmody> 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 together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out. darshanmody> darshanmody> Cheers, darshanmody> Richard darshanmody> darshanmody> In message <25D2EC755404B4409F263AC6D050FEBB2A10781E at AZ-FFEXMB03.global.avaya.com> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" said: darshanmody> darshanmody> darshanmody> Matt, darshanmody> darshanmody> darshanmody> darshanmody> Below is the scenario. darshanmody> darshanmody> darshanmody> darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain. darshanmody> darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app. darshanmody> darshanmody> 3. Connect client with certificates that server does not trust. darshanmody> darshanmody> 4. The connections from client to server fails darshanmody> darshanmody> darshanmody> darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved. darshanmody> darshanmody> darshanmody> darshanmody> Hope this helps darshanmody> darshanmody> darshanmody> darshanmody> Thanks darshanmody> darshanmody> Darshan darshanmody> darshanmody> darshanmody> darshanmody> -----Original Message----- darshanmody> darshanmody> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] darshanmody> darshanmody> On Behalf Of Matt Caswell darshanmody> darshanmody> Sent: Thursday, March 23, 2017 6:55 PM darshanmody> darshanmody> To: openssl-dev at openssl.org darshanmody> darshanmody> Subject: Re: [openssl-dev] Memory leak in application when darshanmody> darshanmody> we use ECDH darshanmody> darshanmody> darshanmody> darshanmody> darshanmody> darshanmody> darshanmody> darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote: darshanmody> darshanmody> > Can you further elaborate? darshanmody> darshanmody> > darshanmody> darshanmody> > What we did is to create a TLS connection and with darshanmody> darshanmody> > invalid certificates from the client and server on darshanmody> darshanmody> > verification would reject the certificate. The cipher darshanmody> darshanmody> > negotiated was ECDHE cipher between client and server. darshanmody> darshanmody> > darshanmody> darshanmody> > This was done with load (multiple while 1 script trying darshanmody> darshanmody> > to connect to server using invalid certificates and in darshanmody> darshanmody> > course of time the memory was increasing). darshanmody> darshanmody> darshanmody> darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. darshanmody> darshanmody> darshanmody> darshanmody> Matt darshanmody> darshanmody> darshanmody> darshanmody> darshanmody> darshanmody> > darshanmody> darshanmody> > Thanks Darshan darshanmody> darshanmody> > darshanmody> darshanmody> > -----Original Message----- From: openssl-dev darshanmody> darshanmody> > [mailto:openssl-dev-bounces at openssl.org] On Behalf Of darshanmody> darshanmody> > Matt Caswell darshanmody> darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: darshanmody> darshanmody> > openssl-dev at openssl.org darshanmody> darshanmody> > Subject: Re: [openssl-dev] Memory leak in application darshanmody> darshanmody> > when we use ECDH darshanmody> darshanmody> > darshanmody> darshanmody> > darshanmody> darshanmody> > darshanmody> darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: darshanmody> darshanmody> >> Matt, darshanmody> darshanmody> >> darshanmody> darshanmody> >> Even after accounting for the EC_KEY we still observe some leak. darshanmody> darshanmody> >> The leak started after we started using supporting EC darshanmody> darshanmody> >> with callback SSL_set_tmp_ecdh_callback(). darshanmody> darshanmody> >> darshanmody> darshanmody> >> The core dump shows the string data of the far-end certificates. darshanmody> darshanmody> >> I cannot pin point the code in openssl with this regard. darshanmody> darshanmody> > darshanmody> darshanmody> > Are you able to create a simple reproducer demonstrating darshanmody> darshanmody> > the problem with the callback? darshanmody> darshanmody> > darshanmody> darshanmody> > Matt darshanmody> darshanmody> > darshanmody> darshanmody> -- darshanmody> darshanmody> openssl-dev mailing list darshanmody> darshanmody> To unsubscribe: darshanmody> darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op darshanmody> darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8 darshanmody> darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK darshanmody> darshanmody> fQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf darshanmody> darshanmody> _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e= darshanmody> darshanmody> -- darshanmody> darshanmody> openssl-dev mailing list darshanmody> darshanmody> To unsubscribe: darshanmody> darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op darshanmody> darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8 darshanmody> darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK darshanmody> darshanmody> fQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q darshanmody> darshanmody> 92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= darshanmody> darshanmody> darshanmody> -- darshanmody> openssl-dev mailing list darshanmody> To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= darshanmody> -- darshanmody> openssl-dev mailing list darshanmody> To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=aM8Nc6bSJzLs-HdERDikYMeQK6uUqvjYvWnfqtvREM4&s=5DECvTKmFHf9urfCwMDaDnk14k9fM_XDkpl9X5r5aJA&e= darshanmody> -- darshanmody> openssl-dev mailing list darshanmody> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev darshanmody> From matt at openssl.org Mon Mar 27 09:33:55 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Mar 2017 10:33:55 +0100 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: <25D2EC755404B4409F263AC6D050FEBB2A108EFC@AZ-FFEXMB03.global.avaya.com> References: <25D2EC755404B4409F263AC6D050FEBB2A1077F2@AZ-FFEXMB03.global.avaya.com> <3fab20f8-b60c-6edc-7922-e184000c987c@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10781E@AZ-FFEXMB03.global.avaya.com> <20170323.150038.1594136336870474788.levitte@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A107853@AZ-FFEXMB03.global.avaya.com> <25D2EC755404B4409F263AC6D050FEBB2A108EFC@AZ-FFEXMB03.global.avaya.com> Message-ID: Hi Darshan The behaviour you are seeing is not particularly surprising and does not indicate a memory leak. s_server maintains a cache of sessions from previous connections to enable the resumption capability. Since your s_client loop isn't resuming it creates a new session every time (which contains the client certificate), so I would expect the memory to grow. To confirm there are no leaks I ran s_server through valgrind and ran your s_client loop. I actually *did* find a minor leak - but it does not grow over time and is constant no matter how many connections are made. It only affects the command line apps and is also quite small (64 bytes on my machine). Fix here: https://github.com/openssl/openssl/pull/3040 This only impacts 1.0.2. It doesn't seem to be a problem in 1.1.0 (probably because of the new auto-deinit capability). Once the above patch was applied running s_server through valgrind with your s_client loop gives me: CONNECTION CLOSED 0 items in the session cache 0 client connects (SSL_connect()) 0 client renegotiates (SSL_connect()) 0 client connects that finished 71 server accepts (SSL_accept()) 0 server renegotiates (SSL_accept()) 70 server accepts that finished 0 session cache hits 0 session cache misses 0 session cache timeouts 0 callback cache hits 0 cache full overflows (128 allowed) ==15312== ==15312== HEAP SUMMARY: ==15312== in use at exit: 0 bytes in 0 blocks ==15312== total heap usage: 230,141 allocs, 230,141 frees, 19,200,644 bytes allocated ==15312== ==15312== All heap blocks were freed -- no leaks are possible ==15312== ==15312== For counts of detected and suppressed errors, rerun with: -v ==15312== Use --track-origins=yes to see where uninitialised values come from ==15312== ERROR SUMMARY: 91846 errors from 1000 contexts (suppressed: 0 from 0) Matt On 27/03/17 09:40, Mody, Darshan (Darshan) wrote: > Matt, Richard, > > I have not created any patch. Instead I am using s_server app provided from Openssl. Below is the server side command run > > openssl s_server -accept -key -cert -CAfile -verify > > On the client side I am running script below > > #/bin/sh > > while [ 1 ] > do > openssl s_client -connect : -cert -key &>/dev/null > done > > Running the client once and printing the results showed the cipher selected was ECDHE cipher. I believe there is inherent leak in the ECDHE side of openssl. > > I find that the server started leaking was leaking. Check the Resident memory and the CPU. Resident memory increases after every 3 second. When I had stopped the client traffic the resident memory did not increase however it did not returned back to what it was earlier. Hope this will help to reproduce the issue. > > top - 10:16:37 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.6%us, 0.1%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 3924288k total, 3757716k used, 166572k free, 78200k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219736k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3528 2740 S 0.0 0.1 0:00.00 openssl > > > top - 10:16:40 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie > Cpu(s): 1.6%us, 0.9%sy, 0.0%ni, 97.4%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st > Mem: 3924288k total, 3757856k used, 166432k free, 78208k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3532 2740 R 4.3 0.1 0:00.13 openssl > > > top - 10:16:43 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 2.6%us, 0.8%sy, 0.1%ni, 96.2%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st > Mem: 3924288k total, 3757980k used, 166308k free, 78232k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3544 2740 S 7.0 0.1 0:00.34 openssl > > > top - 10:16:46 up 46 days, 1:30, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 2.1%us, 1.1%sy, 0.0%ni, 96.5%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st > Mem: 3924288k total, 3757964k used, 166324k free, 78248k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219732k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3560 2740 S 6.7 0.1 0:00.54 openssl > > > top - 10:16:49 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 2.7%us, 1.1%sy, 0.0%ni, 96.0%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st > Mem: 3924288k total, 3758212k used, 166076k free, 78264k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3572 2740 S 8.0 0.1 0:00.78 openssl > > > top - 10:16:52 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.2%us, 1.2%sy, 0.0%ni, 94.8%id, 0.1%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3758212k used, 166076k free, 78288k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219732k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3592 2740 S 11.0 0.1 0:01.11 openssl > > > top - 10:16:55 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.3%us, 1.3%sy, 0.1%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3758584k used, 165704k free, 78288k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3608 2740 S 11.3 0.1 0:01.45 openssl > > > top - 10:16:58 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.3%us, 1.6%sy, 0.0%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st > Mem: 3924288k total, 3758864k used, 165424k free, 78296k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3628 2740 S 11.3 0.1 0:01.79 openssl > > > top - 10:17:01 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.4%us, 1.5%sy, 0.0%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st > Mem: 3924288k total, 3758956k used, 165332k free, 78312k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219740k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40016 3648 2740 S 10.7 0.1 0:02.11 openssl > > > top - 10:17:04 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.9%us, 1.9%sy, 0.0%ni, 91.9%id, 1.6%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 3924288k total, 3759708k used, 164580k free, 78328k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219916k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40016 3668 2740 S 11.0 0.1 0:02.44 openssl > > > top - 10:17:07 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.4%us, 1.2%sy, 0.1%ni, 93.8%id, 0.0%wa, 0.0%hi, 1.4%si, 0.0%st > Mem: 3924288k total, 3759336k used, 164952k free, 78360k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219900k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40016 3688 2740 R 10.7 0.1 0:02.76 openssl > > > top - 10:17:10 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.2%us, 1.6%sy, 0.0%ni, 94.2%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st > Mem: 3924288k total, 3758584k used, 165704k free, 78360k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219916k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40016 3708 2740 S 11.3 0.1 0:03.10 openssl > > > top - 10:17:13 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.6%us, 1.1%sy, 0.0%ni, 94.5%id, 0.0%wa, 0.0%hi, 0.8%si, 0.0%st > Mem: 3924288k total, 3758476k used, 165812k free, 78376k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219920k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40016 3728 2740 S 10.7 0.1 0:03.42 openssl > > > top - 10:17:16 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.8%us, 1.3%sy, 0.0%ni, 93.3%id, 0.0%wa, 0.0%hi, 1.7%si, 0.0%st > Mem: 3924288k total, 3759824k used, 164464k free, 78384k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219920k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40124 3748 2740 S 11.3 0.1 0:03.76 openssl > > --------------- > > top - 10:23:10 up 46 days, 1:36, 2 users, load average: 0.03, 0.05, 0.06 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.6%us, 1.3%sy, 0.1%ni, 94.4%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3756048k used, 168240k free, 75888k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216576k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 42392 6048 2740 S 10.7 0.2 0:41.95 openssl > > > top - 10:23:13 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.2%us, 1.3%sy, 0.0%ni, 94.8%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3756064k used, 168224k free, 75904k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216572k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 42392 6068 2740 S 10.7 0.2 0:42.27 openssl > > > top - 10:23:16 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 > Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.2%us, 1.3%sy, 0.1%ni, 94.9%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st > Mem: 3924288k total, 3756188k used, 168100k free, 75912k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216572k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 42392 6088 2740 R 11.0 0.2 0:42.60 openssl > > > top - 10:23:19 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.1%us, 1.2%sy, 1.6%ni, 93.5%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3756528k used, 167760k free, 75920k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216584k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 42392 6108 2740 S 10.7 0.2 0:42.92 openssl > > > top - 10:23:22 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 11.1%us, 4.6%sy, 20.2%ni, 63.6%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3756924k used, 167364k free, 75952k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216600k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 42500 6124 2740 S 10.3 0.2 0:43.23 openssl > > Thanks > Darshan > > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Mody, Darshan (Darshan) > Sent: Thursday, March 23, 2017 7:40 PM > To: openssl-dev at openssl.org > Cc: Bahr, William G (Bill) > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH > > 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-bounces at openssl.org] On Behalf Of Richard Levitte > Sent: Thursday, March 23, 2017 7:31 PM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH > > 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 together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out. > > Cheers, > Richard > > In message <25D2EC755404B4409F263AC6D050FEBB2A10781E at AZ-FFEXMB03.global.avaya.com> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" said: > > darshanmody> Matt, > darshanmody> > darshanmody> Below is the scenario. > darshanmody> > darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain. > darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app. > darshanmody> 3. Connect client with certificates that server does not trust. > darshanmody> 4. The connections from client to server fails > darshanmody> > darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved. > darshanmody> > darshanmody> Hope this helps > darshanmody> > darshanmody> Thanks > darshanmody> Darshan > darshanmody> > darshanmody> -----Original Message----- > darshanmody> From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] > darshanmody> On Behalf Of Matt Caswell > darshanmody> Sent: Thursday, March 23, 2017 6:55 PM > darshanmody> To: openssl-dev at openssl.org > darshanmody> Subject: Re: [openssl-dev] Memory leak in application when > darshanmody> we use ECDH > darshanmody> > darshanmody> > darshanmody> > darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote: > darshanmody> > Can you further elaborate? > darshanmody> > > darshanmody> > What we did is to create a TLS connection and with > darshanmody> > invalid certificates from the client and server on > darshanmody> > verification would reject the certificate. The cipher > darshanmody> > negotiated was ECDHE cipher between client and server. > darshanmody> > > darshanmody> > This was done with load (multiple while 1 script trying > darshanmody> > to connect to server using invalid certificates and in > darshanmody> > course of time the memory was increasing). > darshanmody> > darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. > darshanmody> > darshanmody> Matt > darshanmody> > darshanmody> > darshanmody> > > darshanmody> > Thanks Darshan > darshanmody> > > darshanmody> > -----Original Message----- From: openssl-dev > darshanmody> > [mailto:openssl-dev-bounces at openssl.org] On Behalf Of > darshanmody> > Matt Caswell > darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: > darshanmody> > openssl-dev at openssl.org > darshanmody> > Subject: Re: [openssl-dev] Memory leak in application > darshanmody> > when we use ECDH > darshanmody> > > darshanmody> > > darshanmody> > > darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: > darshanmody> >> Matt, > darshanmody> >> > darshanmody> >> Even after accounting for the EC_KEY we still observe some leak. > darshanmody> >> The leak started after we started using supporting EC > darshanmody> >> with callback SSL_set_tmp_ecdh_callback(). > darshanmody> >> > darshanmody> >> The core dump shows the string data of the far-end certificates. > darshanmody> >> I cannot pin point the code in openssl with this regard. > darshanmody> > > darshanmody> > Are you able to create a simple reproducer demonstrating > darshanmody> > the problem with the callback? > darshanmody> > > darshanmody> > Matt > darshanmody> > > darshanmody> -- > darshanmody> openssl-dev mailing list > darshanmody> To unsubscribe: > darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op > darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8 > darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK > darshanmody> fQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7sQf > darshanmody> _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e= > darshanmody> -- > darshanmody> openssl-dev mailing list > darshanmody> To unsubscribe: > darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.op > darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8 > darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrK > darshanmody> fQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q > darshanmody> 92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= > darshanmody> > -- > openssl-dev mailing list > To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm8q92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= > -- > openssl-dev mailing list > To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=aM8Nc6bSJzLs-HdERDikYMeQK6uUqvjYvWnfqtvREM4&s=5DECvTKmFHf9urfCwMDaDnk14k9fM_XDkpl9X5r5aJA&e= > From darshanmody at avaya.com Mon Mar 27 12:43:28 2017 From: darshanmody at avaya.com (Mody, Darshan (Darshan)) Date: Mon, 27 Mar 2017 12:43:28 +0000 Subject: [openssl-dev] Memory leak in application when we use ECDH In-Reply-To: References: <25D2EC755404B4409F263AC6D050FEBB2A1077F2@AZ-FFEXMB03.global.avaya.com> <3fab20f8-b60c-6edc-7922-e184000c987c@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A10781E@AZ-FFEXMB03.global.avaya.com> <20170323.150038.1594136336870474788.levitte@openssl.org> <25D2EC755404B4409F263AC6D050FEBB2A107853@AZ-FFEXMB03.global.avaya.com> <25D2EC755404B4409F263AC6D050FEBB2A108EFC@AZ-FFEXMB03.global.avaya.com> Message-ID: <25D2EC755404B4409F263AC6D050FEBB2A108FE2@AZ-FFEXMB03.global.avaya.com> Matt, We have set SSL_CTX_set_session_cache_mode(ctx, /*SSL_SESS_CACHE_SERVER */ SSL_SESS_CACHE_OFF); Do you observe the same behavior with s_server app when we have cache mode set as SSL_SES_CACHE_OFF? Thanks Darshan -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Monday, March 27, 2017 3:04 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Memory leak in application when we use ECDH Hi Darshan The behaviour you are seeing is not particularly surprising and does not indicate a memory leak. s_server maintains a cache of sessions from previous connections to enable the resumption capability. Since your s_client loop isn't resuming it creates a new session every time (which contains the client certificate), so I would expect the memory to grow. To confirm there are no leaks I ran s_server through valgrind and ran your s_client loop. I actually *did* find a minor leak - but it does not grow over time and is constant no matter how many connections are made. It only affects the command line apps and is also quite small (64 bytes on my machine). Fix here: https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openssl_openssl_pull_3040&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=coIwPvyWw4plXoF_ThJsi4JLRt34Sy9UvhnGuHBjYEU&s=VTPuVxG9-V4MA6C5eMla9AZ1hS3cGGFkl6PN3R0bAyA&e= This only impacts 1.0.2. It doesn't seem to be a problem in 1.1.0 (probably because of the new auto-deinit capability). Once the above patch was applied running s_server through valgrind with your s_client loop gives me: CONNECTION CLOSED 0 items in the session cache 0 client connects (SSL_connect()) 0 client renegotiates (SSL_connect()) 0 client connects that finished 71 server accepts (SSL_accept()) 0 server renegotiates (SSL_accept()) 70 server accepts that finished 0 session cache hits 0 session cache misses 0 session cache timeouts 0 callback cache hits 0 cache full overflows (128 allowed) ==15312== ==15312== HEAP SUMMARY: ==15312== in use at exit: 0 bytes in 0 blocks ==15312== total heap usage: 230,141 allocs, 230,141 frees, 19,200,644 bytes allocated ==15312== ==15312== All heap blocks were freed -- no leaks are possible ==15312== ==15312== For counts of detected and suppressed errors, rerun with: -v ==15312== Use --track-origins=yes to see where uninitialised values come from ==15312== ERROR SUMMARY: 91846 errors from 1000 contexts (suppressed: 0 from 0) Matt On 27/03/17 09:40, Mody, Darshan (Darshan) wrote: > Matt, Richard, > > I have not created any patch. Instead I am using s_server app provided > from Openssl. Below is the server side command run > > openssl s_server -accept -key -cert > -CAfile CA> -verify > > On the client side I am running script below > > #/bin/sh > > while [ 1 ] > do > openssl s_client -connect : -cert client certificate not trusted by server> -key certificate key> &>/dev/null done > > Running the client once and printing the results showed the cipher selected was ECDHE cipher. I believe there is inherent leak in the ECDHE side of openssl. > > I find that the server started leaking was leaking. Check the Resident memory and the CPU. Resident memory increases after every 3 second. When I had stopped the client traffic the resident memory did not increase however it did not returned back to what it was earlier. Hope this will help to reproduce the issue. > > top - 10:16:37 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.6%us, 0.1%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 3924288k total, 3757716k used, 166572k free, 78200k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219736k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3528 2740 S 0.0 0.1 0:00.00 openssl > > > top - 10:16:40 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie > Cpu(s): 1.6%us, 0.9%sy, 0.0%ni, 97.4%id, 0.0%wa, 0.0%hi, 0.1%si, 0.0%st > Mem: 3924288k total, 3757856k used, 166432k free, 78208k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3532 2740 R 4.3 0.1 0:00.13 openssl > > > top - 10:16:43 up 46 days, 1:29, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 2.6%us, 0.8%sy, 0.1%ni, 96.2%id, 0.0%wa, 0.0%hi, 0.3%si, 0.0%st > Mem: 3924288k total, 3757980k used, 166308k free, 78232k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3544 2740 S 7.0 0.1 0:00.34 openssl > > > top - 10:16:46 up 46 days, 1:30, 2 users, load average: 0.03, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 2.1%us, 1.1%sy, 0.0%ni, 96.5%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st > Mem: 3924288k total, 3757964k used, 166324k free, 78248k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219732k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3560 2740 S 6.7 0.1 0:00.54 openssl > > > top - 10:16:49 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 2.7%us, 1.1%sy, 0.0%ni, 96.0%id, 0.0%wa, 0.0%hi, 0.2%si, 0.0%st > Mem: 3924288k total, 3758212k used, 166076k free, 78264k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3572 2740 S 8.0 0.1 0:00.78 openssl > > > top - 10:16:52 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.2%us, 1.2%sy, 0.0%ni, 94.8%id, 0.1%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3758212k used, 166076k free, 78288k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219732k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3592 2740 S 11.0 0.1 0:01.11 openssl > > > top - 10:16:55 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.3%us, 1.3%sy, 0.1%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3758584k used, 165704k free, 78288k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3608 2740 S 11.3 0.1 0:01.45 openssl > > > top - 10:16:58 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.3%us, 1.6%sy, 0.0%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st > Mem: 3924288k total, 3758864k used, 165424k free, 78296k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219744k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 39908 3628 2740 S 11.3 0.1 0:01.79 openssl > > > top - 10:17:01 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.08 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.4%us, 1.5%sy, 0.0%ni, 94.7%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st > Mem: 3924288k total, 3758956k used, 165332k free, 78312k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219740k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40016 3648 2740 S 10.7 0.1 0:02.11 openssl > > > top - 10:17:04 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.9%us, 1.9%sy, 0.0%ni, 91.9%id, 1.6%wa, 0.0%hi, 0.7%si, 0.0%st > Mem: 3924288k total, 3759708k used, 164580k free, 78328k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219916k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40016 3668 2740 S 11.0 0.1 0:02.44 openssl > > > top - 10:17:07 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.4%us, 1.2%sy, 0.1%ni, 93.8%id, 0.0%wa, 0.0%hi, 1.4%si, 0.0%st > Mem: 3924288k total, 3759336k used, 164952k free, 78360k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219900k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40016 3688 2740 R 10.7 0.1 0:02.76 openssl > > > top - 10:17:10 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.2%us, 1.6%sy, 0.0%ni, 94.2%id, 0.0%wa, 0.0%hi, 1.0%si, 0.0%st > Mem: 3924288k total, 3758584k used, 165704k free, 78360k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219916k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40016 3708 2740 S 11.3 0.1 0:03.10 openssl > > > top - 10:17:13 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.6%us, 1.1%sy, 0.0%ni, 94.5%id, 0.0%wa, 0.0%hi, 0.8%si, 0.0%st > Mem: 3924288k total, 3758476k used, 165812k free, 78376k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219920k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40016 3728 2740 S 10.7 0.1 0:03.42 openssl > > > top - 10:17:16 up 46 days, 1:30, 2 users, load average: 0.02, 0.06, 0.07 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.8%us, 1.3%sy, 0.0%ni, 93.3%id, 0.0%wa, 0.0%hi, 1.7%si, 0.0%st > Mem: 3924288k total, 3759824k used, 164464k free, 78384k buffers > Swap: 8388604k total, 999556k used, 7389048k free, 219920k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 40124 3748 2740 S 11.3 0.1 0:03.76 openssl > > --------------- > > top - 10:23:10 up 46 days, 1:36, 2 users, load average: 0.03, 0.05, 0.06 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.6%us, 1.3%sy, 0.1%ni, 94.4%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3756048k used, 168240k free, 75888k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216576k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 42392 6048 2740 S 10.7 0.2 0:41.95 openssl > > > top - 10:23:13 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.2%us, 1.3%sy, 0.0%ni, 94.8%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3756064k used, 168224k free, 75904k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216572k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 42392 6068 2740 S 10.7 0.2 0:42.27 openssl > > > top - 10:23:16 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 > Tasks: 1 total, 1 running, 0 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.2%us, 1.3%sy, 0.1%ni, 94.9%id, 0.0%wa, 0.0%hi, 0.4%si, 0.0%st > Mem: 3924288k total, 3756188k used, 168100k free, 75912k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216572k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 42392 6088 2740 R 11.0 0.2 0:42.60 openssl > > > top - 10:23:19 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 3.1%us, 1.2%sy, 1.6%ni, 93.5%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3756528k used, 167760k free, 75920k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216584k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 42392 6108 2740 S 10.7 0.2 0:42.92 openssl > > > top - 10:23:22 up 46 days, 1:36, 2 users, load average: 0.02, 0.04, 0.06 > Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie > Cpu(s): 11.1%us, 4.6%sy, 20.2%ni, 63.6%id, 0.0%wa, 0.0%hi, 0.6%si, 0.0%st > Mem: 3924288k total, 3756924k used, 167364k free, 75952k buffers > Swap: 8388604k total, 998972k used, 7389632k free, 216600k cached > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 27303 root 20 0 42500 6124 2740 S 10.3 0.2 0:43.23 openssl > > Thanks > Darshan > > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf > Of Mody, Darshan (Darshan) > Sent: Thursday, March 23, 2017 7:40 PM > To: openssl-dev at openssl.org > Cc: Bahr, William G (Bill) > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH > > 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-bounces at openssl.org] On Behalf > Of Richard Levitte > Sent: Thursday, March 23, 2017 7:31 PM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] Memory leak in application when we use ECDH > > 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 together, it will be with Our conditions, not yours, and therefore a pretty bad method to figure this out. > > Cheers, > Richard > > In message <25D2EC755404B4409F263AC6D050FEBB2A10781E at AZ-FFEXMB03.global.avaya.com> on Thu, 23 Mar 2017 13:47:10 +0000, "Mody, Darshan (Darshan)" said: > > darshanmody> Matt, > darshanmody> > darshanmody> Below is the scenario. > darshanmody> > darshanmody> 1. Have server open a listen socket which always validates the client certificate and chain. > darshanmody> 2. On server support ECDHE using callback. Ensure the EC_KEY passed to openssl from app is cleaned up by the app. > darshanmody> 3. Connect client with certificates that server does not trust. > darshanmody> 4. The connections from client to server fails > darshanmody> > darshanmody> In course of time the app running the server has been leaking. Even after accounting for the EC_KEY passed by the server app to openssl we find there seems to be leak. Further investigation on the core dumps generated from the server app shows that it has the certificates from the client saved. > darshanmody> > darshanmody> Hope this helps > darshanmody> > darshanmody> Thanks > darshanmody> Darshan > darshanmody> > darshanmody> -----Original Message----- > darshanmody> From: openssl-dev > darshanmody> [mailto:openssl-dev-bounces at openssl.org] > darshanmody> On Behalf Of Matt Caswell > darshanmody> Sent: Thursday, March 23, 2017 6:55 PM > darshanmody> To: openssl-dev at openssl.org > darshanmody> Subject: Re: [openssl-dev] Memory leak in application > darshanmody> when we use ECDH > darshanmody> > darshanmody> > darshanmody> > darshanmody> On 23/03/17 13:19, Mody, Darshan (Darshan) wrote: > darshanmody> > Can you further elaborate? > darshanmody> > > darshanmody> > What we did is to create a TLS connection and with > darshanmody> > invalid certificates from the client and server on > darshanmody> > verification would reject the certificate. The cipher > darshanmody> > negotiated was ECDHE cipher between client and server. > darshanmody> > > darshanmody> > This was done with load (multiple while 1 script trying > darshanmody> > to connect to server using invalid certificates and in > darshanmody> > course of time the memory was increasing). > darshanmody> > darshanmody> Without being able to recreate the problem its going to be very difficult/impossible for us to fix it (assuming the problem is in OpenSSl itself). We would need some simple reproducer code that demonstrates the problem occurring. > darshanmody> > darshanmody> Matt > darshanmody> > darshanmody> > darshanmody> > > darshanmody> > Thanks Darshan > darshanmody> > > darshanmody> > -----Original Message----- From: openssl-dev > darshanmody> > [mailto:openssl-dev-bounces at openssl.org] On Behalf Of > darshanmody> > Matt Caswell > darshanmody> > Sent: Thursday, March 23, 2017 4:09 PM To: > darshanmody> > openssl-dev at openssl.org > darshanmody> > Subject: Re: [openssl-dev] Memory leak in application > darshanmody> > when we use ECDH > darshanmody> > > darshanmody> > > darshanmody> > > darshanmody> > On 23/03/17 10:13, Mody, Darshan (Darshan) wrote: > darshanmody> >> Matt, > darshanmody> >> > darshanmody> >> Even after accounting for the EC_KEY we still observe some leak. > darshanmody> >> The leak started after we started using supporting EC > darshanmody> >> with callback SSL_set_tmp_ecdh_callback(). > darshanmody> >> > darshanmody> >> The core dump shows the string data of the far-end certificates. > darshanmody> >> I cannot pin point the code in openssl with this regard. > darshanmody> > > darshanmody> > Are you able to create a simple reproducer > darshanmody> > demonstrating the problem with the callback? > darshanmody> > > darshanmody> > Matt > darshanmody> > > darshanmody> -- > darshanmody> openssl-dev mailing list > darshanmody> To unsubscribe: > darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta. > darshanmody> op > darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQ > darshanmody> w8 > darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJ > darshanmody> rK > darshanmody> fQ&m=VbrRgO8PZIVkFM4PjeK7TEgKDHnbLu_QfbyqRhmvx8I&s=u0cR7s > darshanmody> Qf _Zz8FoCnrzgLc3drBSR8Ou1qDUyxV8z1xYQ&e= > darshanmody> -- > darshanmody> openssl-dev mailing list > darshanmody> To unsubscribe: > darshanmody> https://urldefense.proofpoint.com/v2/url?u=https-3A__mta. > darshanmody> op > darshanmody> enssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQ > darshanmody> w8 > darshanmody> bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJ > darshanmody> rK > darshanmody> fQ&m=OtZlUFiavvOVqXL900IST85y3pZLikUdEgekBIIyZoI&s=3T5xlm > darshanmody> 8q 92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= > darshanmody> > -- > openssl-dev mailing list > To unsubscribe: > https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_m > ailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEU > LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=OtZlUFiavvOVqXL900IST85y3pZL > ikUdEgekBIIyZoI&s=3T5xlm8q92-eP1ItbDzGOU972l4wFrkJUgLrBNR4Qx8&e= > -- > openssl-dev mailing list > To unsubscribe: > https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_m > ailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEU > LbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=aM8Nc6bSJzLs-HdERDikYMeQK6uU > qvjYvWnfqtvREM4&s=5DECvTKmFHf9urfCwMDaDnk14k9fM_XDkpl9X5r5aJA&e= > -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=bsEULbVnjelD7InzgsegHBEbtXzaIDagy9EuEhJrKfQ&m=coIwPvyWw4plXoF_ThJsi4JLRt34Sy9UvhnGuHBjYEU&s=UUx2DxGuCVxrSicIa6MnjTprasDvG2yZURwlzaCG8bg&e= From matt at openssl.org Mon Mar 27 16:33:47 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 27 Mar 2017 17:33:47 +0100 Subject: [openssl-dev] Code Health Tuesday - documentation! In-Reply-To: <5cac31fb-0d6d-019a-86ec-1d1680121b93@openssl.org> References: <5cac31fb-0d6d-019a-86ec-1d1680121b93@openssl.org> Message-ID: <819bac9e-fbcb-64c9-2468-e19e74c2b940@openssl.org> Just a reminder about this event taking place tomorrow! Matt On 23/03/17 17:57, Matt Caswell wrote: > > 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 documentation, write it and send us a PR on our > github site. Or help us fix incorrect or out-of-date documentation, or > broken links, etc. > > Thanks! > > Matt > > > FAQ: > > Q: How do I participate? > A: Find something to document. Create a Github pull request and put > ?code health? in the title. We?ll be monitoring Github for quick turnaround. > > Q: Which branches should I target? > A: You should target master. If documentation applies to earlier > releases then please indicate which ones in the PR. Sometimes there are > subtle differences between the different releases, so it may be > necessary to create a different PR for older branches. > > Q: What form should the documentation take? > A: All our documentation is in POD file format. Take a look in the doc > directory and read a few of the pages to get used to our style. The > doc/man3/BIO_printf.pod file is a good, recently written example. If you > are providing missing documentation consider whether it should appear in > a new POD file, or whether it should be added to an existing one. > You can use the "doc-nits" script to run some basic checks on the > documentation you have written (run "make doc-nits"). > > Q: Do you have any tools to find what to document? > A: Yes, the doc-nits tool (in the util sub-dir) can provide some useful > info: > ./util/find-doc-nits ?l (references to non-existing POD pages) > ./util/find-doc-nits ?u (all undocumented public functions) > From paul.dale at oracle.com Wed Mar 29 03:41:33 2017 From: paul.dale at oracle.com (Paul Dale) Date: Tue, 28 Mar 2017 20:41:33 -0700 (PDT) Subject: [openssl-dev] Test framework improvements Message-ID: A number of improvements to the output of the C portion of the test framework have been made. Specifically, a number of functions have been added to provide uniform reporting of test case failures. You access this functionality by including "testutil.h" There are two unconditional functions: TEST_info and TEST_error which print informative and error messages respectively. They have no return value and accept a printf format string plus arguments. All of the remaining functions are conditional tests. They return 1 if the condition is true and 0 if false. They output a uniform diagnostic message in the latter case and nothing in the former. The majority of these are of the form TEST_type_cond, where _type_ is the type being tested and _cond_ is the relation being tested. The currently available types are: type C type int int uint unsigned int char char uchar unsigned char long long ulong unsigned long size_t size_t ptr void * str char * mem void *, size_t For the integral types, cond can be: cond C comparison eq == ne != gt > ge >= lt < le <= For the pointer types, cond can only be _eq_ or _ne_. In the case of _str_ and _mem_, the memory pointed to is compared. For _ptr_ just the pointer themselves are compared. The _mem_ comparisons take a pair of pointers + sizes as arguments (i.e. ptr1, size1, ptr2, size2). There are two additional short hand calls for ptr: TEST_ptr ptr != NULL TEST_ptr_null ptr == NULL Finally, there are two calls to check Boolean values: TEST_true checks for != 0 TEST_false checks for == 0 In all cases, it is up to the test executable to process the return codes and to indicate success or failure to the PERL test framework. This would usually be done using: if (!TEST_cond(args)) return 0; See the brief notes at the end of test/README and look at some of the test cases that have been converted already: test/asn1_internal_test.c test/cipherlist_test.c test/crltest.c test/lhash_test.c test/mdc2_internal_test.c test/pkey_meth_test.c test/poly1305_internal_test.c test/ssl_test.c test/ssl_test_ctx_test.c test/stack_test.c test/tls13encryptiontest.c test/tls13secretstest.c test/x509_internal_test.c test/x509_time_test.c To see some examples output of failing tests, test the test_test case: make test TESTS=test_test VERBOSE=1 To see examples of all of the new test functions have a look in test/test_test.c This features both passing and failing calls. However, the actual error handling is not normal for a test executable because it treats desired failures as passes. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia From matt at openssl.org Wed Mar 29 09:06:18 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 29 Mar 2017 10:06:18 +0100 Subject: [openssl-dev] Code Health Tuesday - documentation! In-Reply-To: <5cac31fb-0d6d-019a-86ec-1d1680121b93@openssl.org> References: <5cac31fb-0d6d-019a-86ec-1d1680121b93@openssl.org> Message-ID: <49036dc1-d656-d0e7-5082-14b929490037@openssl.org> On 23/03/17 17:57, Matt Caswell wrote: > 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 documentation, write it and send us a PR on our > github site. Or help us fix incorrect or out-of-date documentation, or > broken links, etc. We held another successful event yesterday. We saw a wide variety of submissions - all focussed on improving our documentation, from simple typos and grammar fixes, to missing command line option documentation and whole new pod pages. There were 16 PRs raised during the event, of which all but 1 have now been pushed through to closure. The "find-doc-nits" script tells me that those PRs provided new documentation for 30 public API functions!! Many thanks to all those that took part. Matt From wrowe at rowe-clan.net Wed Mar 29 20:01:55 2017 From: wrowe at rowe-clan.net (William A Rowe Jr) Date: Wed, 29 Mar 2017 15:01:55 -0500 Subject: [openssl-dev] please make clear on website that 1.1.0e is Development release, not GA / Production release In-Reply-To: References: Message-ID: On Mon, Mar 20, 2017 at 5:41 PM, Jason Vas Dias wrote: > Hi - much thanks for many years of great OpenSSL releases, > but this 1.1.0 branch, IMHO, should not be put above the 1.0.2k > release on the website as the 'latest / best OpenSSL release' - this just > wastes everybody's time . No using software can use this release, > such as the latest releases of OpenSSH, ISC BIND (named) / ISC DHCP, ntpd > (... the list can go on and on - does the latest httpd compile with it? ) > without major restructuring . Just to add to your list, Apache httpd 2.4.26 will support 1.1.0 (and those patches are already on the 2.4 development branch.) That said, 1.1.0 is the latest, and most complete (best) implementation. That information was not incorrect. Perhaps the team could add "most widely adopted" to the description of 1.0.2 for the time being, until the released sources of many common tools do adopt the necessary API changes? But that really isn't the OpenSSL project's issue. The Apache httpd project is also looking at how to efficiently adopt PCRE 10, which is *long* established as the best/current software since a refactoring some years ago, and somewhat similarly neglected by consuming projects. It is not the OSS author's job to strong-arm downstream (e.g. dependent) projects, but simply to provide the best OSS they can. When it breaks you get to keep every line of source code. From zshrdlu at gmail.com Thu Mar 30 17:55:24 2017 From: zshrdlu at gmail.com (Winter Mute) Date: Thu, 30 Mar 2017 20:55:24 +0300 Subject: [openssl-dev] Query about CRLDistributionPoints extension data Message-ID: Hello, All certificates I have encountered with this extension seem to have a problem with the encoding of the distributionPoint. According to the specs: DistributionPointName ::= CHOICE { fullName [0] GeneralNames, nameRelativeToCRLIssuer [1] RelativeDistinguishedName } x509 implementations seem to confuse the "GeneralNames" with "GeneralName". The distinction is that the former is a sequence consisting of one or more instances of the latter, i.e: GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName Am I wrong about this? How does openssl parse this extension? -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Fri Mar 31 01:38:51 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 31 Mar 2017 01:38:51 +0000 Subject: [openssl-dev] Query about CRLDistributionPoints extension data In-Reply-To: References: Message-ID: <20170331013851.GA8889@openssl.org> On Thu, Mar 30, 2017, Winter Mute wrote: > Hello, > All certificates I have encountered with this extension seem to have a > problem with the encoding of the distributionPoint. > According to the specs: > > DistributionPointName ::= CHOICE { > fullName [0] GeneralNames, > nameRelativeToCRLIssuer [1] RelativeDistinguishedName } > > x509 implementations seem to confuse the "GeneralNames" with "GeneralName". > The distinction is that the former is a sequence consisting of one or more > instances of the latter, i.e: > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName > > Am I wrong about this? How does openssl parse this extension? OpenSSL has never had a problem parsing this extension and it complies with the specs. If it did have a problem it wouldn't be able to display the contents of the extension. Note that you wont see the SEQUENCE tag for the SEQUENCE OF GeneralName because it is implicitly tagged. Can you point to an example of a certificate where you think it is incorrectly encoded? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From zshrdlu at gmail.com Fri Mar 31 09:47:15 2017 From: zshrdlu at gmail.com (Winter Mute) Date: Fri, 31 Mar 2017 12:47:15 +0300 Subject: [openssl-dev] Query about CRLDistributionPoints extension data In-Reply-To: <20170331013851.GA8889@openssl.org> References: <20170331013851.GA8889@openssl.org> Message-ID: I see, you're right. The contents octets do indeed contain the GeneralNames sequence. Thanks for clearing this up! On Fri, Mar 31, 2017 at 4:38 AM, Dr. Stephen Henson wrote: > On Thu, Mar 30, 2017, Winter Mute wrote: > > > Hello, > > All certificates I have encountered with this extension seem to have a > > problem with the encoding of the distributionPoint. > > According to the specs: > > > > DistributionPointName ::= CHOICE { > > fullName [0] GeneralNames, > > nameRelativeToCRLIssuer [1] RelativeDistinguishedName } > > > > x509 implementations seem to confuse the "GeneralNames" with > "GeneralName". > > The distinction is that the former is a sequence consisting of one or > more > > instances of the latter, i.e: > > > > GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName > > > > Am I wrong about this? How does openssl parse this extension? > > OpenSSL has never had a problem parsing this extension and it complies with > the specs. If it did have a problem it wouldn't be able to display the > contents of the extension. > > Note that you wont see the SEQUENCE tag for the SEQUENCE OF GeneralName > because it is implicitly tagged. > > Can you point to an example of a certificate where you think it is > incorrectly > encoded? > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From raja.ashok at huawei.com Fri Mar 31 17:54:20 2017 From: raja.ashok at huawei.com (Raja ashok) Date: Fri, 31 Mar 2017 17:54:20 +0000 Subject: [openssl-dev] In ssl3_write_bytes, some checks related to hanlding write failure are missing Message-ID: Hi All, In ssl3_write_bytes, if (len < tot) we are returning failure with SSL_R_BAD_LENGTH error. In this place I hope we should set ?tot? back to ?s->s3->wnum?. Otherwise when application calls back SSL_write with correct buffer, it causes serious problem (?tot? is 0 and iLeft is not NULL). I hope we should do like below. if (len < tot) { s->s3->wnum = tot; SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH); return (-1); } And also we should do one additional check for ?len? as mentioned in my previous mail. if ((len < tot) || ((tot != 0) && (len < (tot + s->s3->wpend_tot)))){ s->s3->wnum = tot; SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH); return (-1); } Regards, Ashok ________________________________ [Company_logo] Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ________________________________ ???????????????????????????????????????? ???????????????????????????????????????? ??????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! From: Raja ashok Sent: 27 March 2017 13:55 To: 'openssl-users at openssl.org'; 'openssl-dev at openssl.org' Subject: In ssl3_write_bytes, some checks related to hanlding write failure are missing Hi, I feel there is a check missing in ssl3_write_bytes, in case of handling write failure. Consider SSL_write is called with 20000 bytes buffer, then internally in ssl3_write_bytes we try to send it as two record (16384 and 3616). If TCP send failed for the second record then we store the states internally (wnum, wpend_tot and wpend_buf) and return back the result. Later application has to call SSL_write with same buffer, if it calls with different buffer of length 100 byte then we fail that in ssl3_write_bytes using the check (len < tot). But consider application calls with buffer of size 18000 bytes and SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER is enabled. Then (len < tot) will not succeed as tot is 16384. Then it will call ssl3_write_pending to send the remaining 3616 record. If it succeeds we are incrementing tot, (tot += i). Now tot will have 20000. Later there is a check (tot == len), this will not succeed. Then directly we are doing n = (len - tot), this will overflow and store a value close to 2^32 in n. Then it will cause out of bound access to the application buffer "buf". I hope we should have one more check (len < (tot + s->s3->wpend_tot)) before calling ssl3_write_pending. if ((len < tot) || (len < (tot + s->s3->wpend_tot))){ SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH); return (-1); } Note : I am referring 1.0.2k version of OpenSSL. Regards, Ashok ________________________________ [Company_logo] Raja Ashok V K Huawei Technologies Bangalore, India http://www.huawei.com ________________________________ ???????????????????????????????????????? ???????????????????????????????????????? ??????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 6737 bytes Desc: image002.jpg URL: