Re: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible
--On Saturday, March 25, 2017 6:16 PM -0400 Theodore Ts'o <ty...@mit.edu> 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: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Friday, March 24, 2017 1:49 PM -0700 James Bottomley <james.bottom...@hansenpartnership.com> 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 <https://en.wikipedia.org/wiki/GPL_linking_exception>, 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: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Friday, March 24, 2017 9:02 PM +0100 Florian Weimer <f...@deneb.enyo.de> 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: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Friday, March 24, 2017 12:30 PM -0700 James Bottomley <james.bottom...@hansenpartnership.com> 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 <http://blogs.fsfe.org/ciaran/?p=58> (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: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Friday, March 24, 2017 7:47 PM +0100 Kurt Roeckx <k...@roeckx.be> wrote: On Fri, Mar 24, 2017 at 10:18:40AM -0700, Quanah Gibson-Mount wrote: --On Friday, March 24, 2017 6:12 PM + "Salz, Rich" <rs...@akamai.com> 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 <https://www.mozilla.org/en-US/MPL/2.0/FAQ/> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Friday, March 24, 2017 6:30 PM + "Salz, Rich" <rs...@akamai.com> 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 <https://www.mozilla.org/en-US/MPL/2.0/combining-mpl-and-gpl/>, "Unmodified MPL-licensed Files - MPL-only". --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Friday, March 24, 2017 6:12 PM + "Salz, Rich" <rs...@akamai.com> 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: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Friday, March 24, 2017 5:40 PM + "Salz, Rich" <rs...@akamai.com> 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: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Friday, March 24, 2017 6:00 PM +0100 Dirk-Willem van Gulik <di...@webweaving.org> 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: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Friday, March 24, 2017 2:17 PM + "Salz, Rich" <rs...@akamai.com> 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: <http://en.swpat.org/wiki/Patent_clauses_in_software_licences#Apache_License_2.0> <http://en.swpat.org/wiki/MPL_and_patents> 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: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Friday, March 24, 2017 1:37 AM + Peter Waltenberg <pwal...@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. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] License change agreement
--On Thursday, March 23, 2017 11:41 AM -0400 Rich Salz <rs...@openssl.org> 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: <http://www.symas.com> -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine
--On Wednesday, August 24, 2016 5:47 PM -0700 Quanah Gibson-Mount <qua...@zimbra.com> wrote: this is clearly a TLS client-side stack trace. Why is nginx acting as an SSL/TLS client? It's a proxy server... so it's proxying between the client connecting to nginx on the IMAPS port and the jetty server on the other side. so: end user <-> nginx:143 <-> jetty:7143 The issue only happens when proxying IMAP on port 143 with startTLS or 993 (IMAPS). It does not occur on POP w/ starttls or web traffic (443). It also is only happening with this one particular client, as we have numerous customers (and our own setup) not experiencing this issue. I'll have them supply what's in their keystore that Jetty's using as well. Note, when this happens, the nginx log shows: 2016/08/22 03:12:10 [info] 530#0: *3326370 SSL_do_handshake() failed (SSL: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:SSL alert number 46) w *** Error in `nginx: worker process': free(): invalid size: 0x010cf560 *** The CA certs in play are the same for both the jetty process being proxied to, and what nginx is using. I see nothing unusual about the server cert on the jetty side. Is there any more info I can provide? --Quanah -- Quanah Gibson-Mount -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine
--On Thursday, August 25, 2016 12:36 AM + Viktor Dukhovni <openssl-us...@dukhovni.org> wrote: On Wed, Aug 24, 2016 at 11:17:21PM +, Quanah Gibson-Mount via RT wrote: When a process (nginx in this case) has this as the server cert, it core dumps with an abort() when clients request the cert: You say the server dumps core, and yet: # 1 0x7f22ba125ce8 in __GI_abort () at abort.c:90 [...] # 14 0x7f22bac435ec in d2i_X509 (a=a@entry=0x0, in=in@entry=0x7ffc53c49a60, len=len@entry=1517) at x_x509.c:143 # 15 0x7f22baf71da2 in ssl3_get_server_certificate # (s=s@entry=0x2167a50) at s3_clnt.c:1228 # 16 0x7f22baf76cee in ssl3_connect (s=0x2167a50) at s3_clnt.c:345 # 17 0x7f22baf8166e in ssl23_get_server_hello (s=0x2167a50) at s23_clnt.c:799 # 18 ssl23_connect (s=0x2167a50) at s23_clnt.c:228 this is clearly a TLS client-side stack trace. Why is nginx acting as an SSL/TLS client? It's a proxy server... so it's proxying between the client connecting to nginx on the IMAPS port and the jetty server on the other side. so: end user <-> nginx:143 <-> jetty:7143 The issue only happens when proxying IMAP on port 143 with startTLS or 993 (IMAPS). It does not occur on POP w/ starttls or web traffic (443). It also is only happening with this one particular client, as we have numerous customers (and our own setup) not experiencing this issue. I'll have them supply what's in their keystore that Jetty's using as well. --Quanah -- Quanah Gibson-Mount -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine
s_cycle (cycle=0x1e86db0) at src/os/unix/ngx_process_cycle.c:241 #27 0x004075fb in main (argc=3, argv=0x7ffc53c4a278) at src/core/nginx.c:407 Let me know what further information I can provide. --Quanah -- Quanah Gibson-Mount -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4658 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4564] BUG: Deadlock in OpenSSL with OpenSSL 1.0.1j and later (including 1.0.2h) with multiple long lived connections
}, {ltk_key = 0x7f3c6bb18ec6 ,
ltk_data =
0xafae000,
ltk_free = 0x7f3c6bb18ea3 }, {ltk_key =
0x7f3c6bb1589f , ltk_data = 0xacae000, ltk_free =
0x7f3c6bb15857 }, {
ltk_key = 0x0, ltk_data = 0x5a17200, ltk_free = 0x0},
{ltk_key =
0x0, ltk_data = 0x0, ltk_free = 0x0} }}
kctx = 0x0
i = 32
keyslot = 410
hash = 616821146
pool_lock = 0
freeme = 0
__PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper"
#19 0x7f3c70552184 in start_thread (arg=0x7f1467c97700) at
pthread_create.c:312
__res =
pd = 0x7f1467c97700
now =
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {139725617329920,
-1093867468031317215, 0, 0, 139725617330624, 139725617329920,
1078896641691560737, 1056426161274956577},
mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0},
data =
{prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call =
pagesize_m1 =
sp =
freesize =
__PRETTY_FUNCTION__ = "start_thread"
#20 0x7f3c7027f37d in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:111
No locals.
Thread 1 (Thread 0x7f3c71694780 (LWP 16804)):
#0 0x7f3c7055365b in pthread_join (threadid=139725667686144,
thread_return=0x0) at pthread_join.c:92
_tid = 16805
_buffer = {__routine = 0x7f3c70553590 , __arg =
0x7f146ac9dd28,
__canceltype = 1791612672, __prev = 0x0}
oldtype = 0
pd = 0x7f146ac9d700
self = 0x7f3c71694780
result = 0
#1 0x7f3c70fe80b2 in ldap_pvt_thread_join (thread=139725667686144,
thread_return=0x0) at thr_posix.c:197
No locals.
#2 0x00438cc0 in slapd_daemon () at daemon.c:2910
i = 0
rc = 0
#3 0x00414ce1 in main (argc=9, argv=0x7ffe003b02b8) at main.c:1017
i = 9
no_detach = 0
rc = 0
urls = 0x1d8a000 "ldap://ldap02e.zimbra.com:389
ldaps://ldap02e.zimbra.com:636 ldapi:///"
username = 0x1d7a010 "root"
groupname = 0x0
sandbox = 0x0
syslogUser = 128
pid = 0
waitfds = {10, 11}
g_argc = 9
g_argv = 0x7ffe003b02b8
configfile = 0x0
configdir = 0x1d82020 "/opt/zimbra/data/ldap/config"
serverName = 0x7ffe003b0d78 "slapd"
serverMode = 1
scp = 0x0
scp_entry = 0x0
debug_unknowns = 0x0
syslog_unknowns = 0x0
serverNamePrefix = 0x4f9608 ""
l = 739235890461816576
slapd_pid_file_unlink = 1
slapd_args_file_unlink = 1
firstopt = 0
__PRETTY_FUNCTION__ = "main"
(gdb)
--
Quanah Gibson-Mount
Platform Architect
Manager, Systems Team
Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
A division of Synacor, Inc
--
Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4564
Please log in as guest with password guest if prompted
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL 1.1 X509_NAME issues
--On Thursday, January 21, 2016 5:58 PM + Howard Chu <h...@highlandsun.com> wrote: In OpenLDAP we reference X509_NAME->bytes->data directly, we want the DER bytes which we then pass thru our own DN validator/formatter. This no longer works with OpenSSL 1.1 and I don't see any provided method to return the DER bytes. I don't want a malloc'd copy, I just want read-only access to the bytes already cached inside the X509_NAME structure. for reference: https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o. c#L448 https://github.com/openldap/openldap/blob/master/libraries/libldap/tls_o. c#L475 Any update on this request? Thanks, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upcoming build system change
--On Monday, January 25, 2016 12:05 AM +0100 Richard Levitte <levi...@openssl.org> wrote: quanah> Actually it was Ubuntu rather than RHEL. Unfortuantely, beyond that, quanah> we're lacking on details, other than it was a perl found in quanah> /usr/local/bin. Ok, so I take it someone had made a local build and installation of perl and forgot to clear it out when the perl package was installed. That *ahem* happens to me at times. That's nothing the OpenSSL build can have any control over, or env. Generally speaking, '#!/usr/bin/env perl' is the right thing to do, really. Yeah, I'm primarily noting it so that if it comes up in the future, there's an idea as to what the solution is for the end user (fix their path, etc). --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upcoming build system change
--On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte <levi...@openssl.org> wrote: A more portable fix would be # !/usr/bin/env perl Yes. Thanks for the reminder. Hm, we did that in some script in Zimbra, and it ended up causing segfaults on RHEL systems that were pulling in a different perl than the system perl. I'll see if I can track down exactly what the issue was. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upcoming build system change
--On Sunday, January 24, 2016 11:30 PM +0100 Richard Levitte <levi...@openssl.org> wrote: In message <DE9F941D87C9EE5AEFAAB903@[192.168.1.9]> on Sun, 24 Jan 2016 12:36:29 -0800, Quanah Gibson-Mount <qua...@zimbra.com> said: quanah> --On Sunday, January 24, 2016 9:32 AM +0100 Richard Levitte quanah> --<levi...@openssl.org> wrote: quanah> quanah> >> A more portable fix would be quanah> >># !/usr/bin/env perl quanah> > quanah> > Yes. Thanks for the reminder. quanah> quanah> Hm, we did that in some script in Zimbra, and it ended up causing quanah> segfaults on RHEL systems that were pulling in a different perl than quanah> the system perl. I'll see if I can track down exactly what the issue quanah> was. Sounds like crappy $PATH... Actually it was Ubuntu rather than RHEL. Unfortuantely, beyond that, we're lacking on details, other than it was a perl found in /usr/local/bin. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Configure --prefix and --openssldir
--On Tuesday, January 19, 2016 7:06 PM +0100 Richard Levitte <levi...@openssl.org> wrote: Hi, I'd like to ask developers and packagers out there, how are the configuration options --prefix and --openssldir working out for you? When I look at them today, they look... well, a bit aged, and could use a refreshment. But before doing anything with these options, I'd like to know how you guys are using them, and how they could be better. For Zimbra 8.7, we are doing: ./Configure no-idea enable-ec_nistp_64_gcc_128 no-mdc2 no-rc5 no-ssl2 \ no-hw --prefix=/opt/zimbra/common --libdir=lib --openssldir=/opt/zimbra/common/etc/ssl \ shared linux-x86_64 -g -O2 -DOPENSSL_NO_HEARTBEATS For previous versions of Zimbra, we did: ./Configure no-idea enable-ec_nistp_64_gcc_128 no-mdc2 no-rc5 no-ssl2 no-hw --prefix=/opt/zimbra/openssl-$(OPENSSL_VERSION) --libdir=lib \ shared $(PLAT) -g -O2 -DOPENSSL_NO_HEARTBEATS; \ So we've only just recently started using openssldir, but it does exactly what we want it to do. ;) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Openssl 1.1
--On Wednesday, December 30, 2015 5:24 PM + "Salz, Rich" <rs...@akamai.com> wrote: So the term "ldap" caught my eye. What surprises are we talking about? ;) I can do some testing for OpenLDAP. I honestly haven't been paying exceedingly close attention to the 1.1 tree. We've made many changes to make various structures SSL, SSL_CTX, RSA, EVP objects., etc., opaque. (Among other things, this makes future shared lib updates easier.) So pulling down the master branch and doing a build and seeing what breaks will be helpful. Great, I'll do that. :) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Openssl 1.1
--On Wednesday, December 30, 2015 5:02 PM + "Salz, Rich" <rs...@akamai.com> wrote: Are Openssh, DNS developers, SMTP/POP3/IMAP developers, FTP devleopers, HTTPD developers and LDAP developers aware of changes coming down the pipe? If not, they should be informed. We've posted about it several times. We're making explicit pre-release testing versions available. We've seen other folks (e.g., CURL) post about their experiences. Do you have any suggestions? We'd hate for 'surprises' to delay people to start using it. So the term "ldap" caught my eye. What surprises are we talking about? ;) I can do some testing for OpenLDAP. I honestly haven't been paying exceedingly close attention to the 1.1 tree. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.0.1q released (corrected download)
--On Thursday, December 03, 2015 11:28 AM -0800 Quanah Gibson-Mount <qua...@zimbra.com> wrote: After adding "make depend" to occur before "make all", it now succeeds. However, this worked on prior releases, so it seems that requiring "make depend" is new to 1.0.1q. Filed this via RT this AM, but it hasn't shown up since it's waiting on moderation. Also filed as <https://github.com/openssl/openssl/issues/492> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.0.1q released (corrected download)
--On Thursday, December 03, 2015 7:18 PM + Matt Caswell <m...@openssl.org> wrote: On 03/12/15 19:10, Quanah Gibson-Mount wrote: make[5]: *** No rule to make target `../../include/openssl/idea.h', needed by `e_idea.o'. Stop. Hmmm. I don't get that. Can you post your build steps? Configure is: ./Configure no-idea enable-ec_nistp_64_gcc_128 no-mdc2 no-rc5 no-ssl2 \ no-hw --prefix=/opt/zimbra/common --libdir=lib --openssldir=/opt/zimbra/common/etc/ssl \ shared linux-x86_64 -g -O2 -DOPENSSL_NO_HEARTBEATS then: LD_RUN_PATH=/opt/zimbra/common/lib make I only see it on Ubuntu12 & Ubuntu14. It works fine on RHEL6/RHEL7 with the same Configure parameters. I see one difference, in that on RHEL, we're running make depend before running make all. After adding "make depend" to occur before "make all", it now succeeds. However, this worked on prior releases, so it seems that requiring "make depend" is new to 1.0.1q. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.0.1q released (corrected download)
source/ The distribution file name is: o openssl-1.0.1q.tar.gz Size: 4549898 MD5 checksum: 54538d0cdcb912f9bc2b36268388205e SHA1 checksum: c65a7bec49b72092d7ebb97a263c496cc1e1d6af SHA256 checksum: b3658b84e9ea606a5ded3c972a5517cd785282e7ea86b20c78aa4b773a047fb7 The checksums were calculated using the following commands: openssl md5 openssl-1.0.1q.tar.gz openssl sha1 openssl-1.0.1q.tar.gz openssl sha256 openssl-1.0.1q.tar.gz Yours, The OpenSSL Project Team. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWYJCeAAoJENnE0m0OYESRQqsIAL/W3CN6X1Lm5cySm0ludaxX 7GZTIIjQjoPLu5UFhgHb0MlYFxvU2CgeahpR8wCFI/s10/enGs7bD54chlBJMqZC C+7+QWq6oY45f2Jnb5toGWK7jkWSW6ASkwTfvK086D+XlIGwgokI1cy3nL+UhdVl YHPb5hoR51l6rMQBB3uR1k2SXp3CEanMnJ1vL81gY05gPkc8qGfFaDj7JrteyOcB o+vwqaGg/J6VIPQIlxC46xeANAg6H3uDXHHjbOYyGHdNRhkQHaFx7c85dIHv8WJ5 J1XXcEmAae4Th+LCQkSu7IKr4Qezr0sw2xMnRgne7oytgYQpyY4xbkTdBFoFtTA= =2dkv -END PGP SIGNATURE- ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] deadlock issue with OpenSSL 1.0.1j
--On Monday, May 18, 2015 3:32 PM -0700 Quanah Gibson-Mount <qua...@zimbra.com> wrote: We've been seeing a problem with openssl deadlocking in the 1.0.1j release that didn't occur in previous releases. I've looked over the change log fixes for the k, l, and m releases, but I haven't seen anything that appears to resolve a deadlock problem. Does anyone know of such an issue that was released since 1.0.1j? Looks like this actually had to do with using a new module in OpenLDAP that had incorrect symbol names that caused classes with various TLS modules. This was fixed in OpenLDAP 2.4.43 (<http://www.openldap.org/its/index.cgi/?findid=8294>) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4165] 1.0.1q release busted, does not compile
make[5]: Leaving directory `/home/build/p4/zimbra/main/ThirdParty/openssl/tmp/UBUNTU14_64/zimbra-openssl/crypto/err' making all in crypto/evp... make[5]: Entering directory `/home/build/p4/zimbra/main/ThirdParty/openssl/tmp/UBUNTU14_64/zimbra-openssl/crypto/evp' gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2 -c -o encode.o encode.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2 -c -o digest.o digest.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2 -c -o evp_enc.o evp_enc.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2 -c -o evp_key.o evp_key.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2 -c -o evp_acnf.o evp_acnf.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2 -c -o evp_cnf.o evp_cnf.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2 -c -o e_des.o e_des.c gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -O2 -DOPENSSL_NO_HEARTBEATS -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -D_FORTIFY_SOURCE=2 -c -o e_bf.o e_bf.c make[5]: *** No rule to make target `../../include/openssl/idea.h', needed by `e_idea.o'. Stop. -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] deadlock issue with OpenSSL 1.0.1j
--On Thursday, December 03, 2015 12:30 PM -0800 Quanah Gibson-Mount <qua...@zimbra.com> wrote: --On Monday, May 18, 2015 3:32 PM -0700 Quanah Gibson-Mount <qua...@zimbra.com> wrote: We've been seeing a problem with openssl deadlocking in the 1.0.1j release that didn't occur in previous releases. I've looked over the change log fixes for the k, l, and m releases, but I haven't seen anything that appears to resolve a deadlock problem. Does anyone know of such an issue that was released since 1.0.1j? Looks like this actually had to do with using a new module in OpenLDAP that had incorrect symbol names that caused classes with various TLS modules. This was fixed in OpenLDAP 2.4.43 (<http://www.openldap.org/its/index.cgi/?findid=8294>) s/classes/clashes/ ;) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.0.1q released (corrected download)
--On Thursday, December 03, 2015 8:51 PM + Matt Caswell <m...@openssl.org> wrote: So it does explicitly tell you to run "make depend". I'm not sure I'd call it a regression that you got away with it before!! I would say it is a regression because it worked for all prior 1.0.1[a-p], and all the releases of 1.0.0 and 0.9.8 that I used prior to moving to the 1.0.1 series. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4153] [PATCH] Fix grammar errors in s_client.c
This patch fixes small grammar errors in s_client.c. <https://github.com/openssl/openssl/pull/481> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Saturday, November 21, 2015 12:50 PM +0100 Kurt Roeckx <k...@roeckx.be> wrote: I would like to point out that GPLv2 also isn't compatible with GPLv3, and that that is causing just as much problems as the current OpenSSL license. Both the GPLv3 and Apache 2.0 have protection for patents, which is why it's not compatible with the GPLv2. If you look at the above page, they recommand the Apache 2.0 license instead of the MIT license just because of that. We are in a field were people do claim patents. So the question is if this patent protection is important for us or not. So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible with the GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has patent language along the same lines as the APLv2. I haven't looked into it and I am not a lawyer, but would it be possible to dual license via the MPLv2 and the APLv2? If so, that would keep the patent protections and allow both GPLv2 and GPLv3 compatibility. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Saturday, November 21, 2015 10:32 PM + "Salz, Rich" <rs...@akamai.com> wrote: Sorry, that answer -- quoting a claim -- does not answer my question. If the issue between APL and GPL2 is patent, then how can MPL2 address both? The GNU folks clearly state that they are compatible: <http://www.gnu.org/licenses/license-list.en.html#MPL-2.0> The reason appears to be that the MPLv2 *specifically* grants compatibility with the GPLv2+ as a part of its terms, whereas the APL does not. <https://en.wikipedia.org/wiki/Mozilla_Public_License#Compatibility_with_other_licenses> <https://www.mozilla.org/en-US/MPL/2.0/>, see section 1.12 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Saturday, November 21, 2015 11:12 PM + "Salz, Rich" <rs...@akamai.com> wrote: The GNU folks clearly state that they are compatible: Interesting. We'll look at it. Thanks. Don't get your hopes up :) Thank you for being willing to take the time to look into it. :) If compatibilty with the GPLv2 and GPLv3 could be resolved with relicensing while keeping the patent portions in place, it would be a major win for the community. :) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Saturday, November 21, 2015 8:24 PM +0100 Kurt Roeckx <k...@roeckx.be>
wrote:
So the MPLv2 is compatible with the APLv2. The MPLv2 is compatible with
the GPLv2 and the APLv2 is copmatible with GPLv3. The MPLv2 has patent
language along the same lines as the APLv2. I haven't looked into it
and I am not a lawyer, but would it be possible to dual license via the
MPLv2 and the APLv2? If so, that would keep the patent protections and
allow both GPLv2 and GPLv3 compatibility.
I think the answer to that is complicated. The safest way to look
at this, at what most people seem to be doing, is that if it all
ends up in 1 "program", all licenses must be complied with at the
same time and so must be compatible.
That's an interesting take I've not encountered. Our legal office has us
elect specifically which license we will be using when pulling in software
with multiple licenses.
For example:
amqp-client-3.5.0
This package, the RabbitMQ Java client library, is triple-licensed under
the Mozilla Public License 1.1 ("MPL"), the GNU General Public License
version 2 ("GPL") and the Apache License version 2 ("ASL"). For the MPL,
please see LICENSE-MPL-RabbitMQ. For the GPL, please see LICENSE-GPL2.
For the ASL, please see LICENSE-APACHE2.
[PLEASE NOTE: ZIMBRA, INC. ELECTS TO USE AND DISTRIBUTE THIS COMPONENT
UNDER THE TERMS OF THE Apache License, V2.0. PLEASE SEE THE APPENDIX TO
REVIEW THE FULL TEXT OF ASL 2.0. THE ORIGINAL LICENSE TERMS ARE REPRODUCED
BELOW ONLY AS A REFERENCE]
(etc).
Since you already cannot mix GPLv2 and GPLv3, then those who need openssl
for GPLv2 reasons could elect to choose the MPLv2, and those who need
openssl for GLPv3 reasons could elect to choose the APLv2.
--Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Saturday, November 21, 2015 10:07 PM + "Salz, Rich" <rs...@akamai.com> wrote: I don't see how MPL2 can have patent protection when it is the patent protection that cases GPL2 to be incompatible with APL2. MPL version 2.0 is compatible with both the Apache License[11] and by default "the GNU GPL version 2.0, the GNU LGPL version 2.1, the GNU AGPL version 3.0, and all later versions of those licenses". It would seem, then, that the MPLv2 covers all cases (GPLv2, GPLv3, etc). I have not looked into it and I am not a lawyer. <http://en.swpat.org/wiki/Patent_clauses_in_software_licences#Apache_License_2.0> <http://en.swpat.org/wiki/MPL_and_patents> Both contain a retaliation clause and a patent grant. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Tuesday, August 04, 2015 3:35 PM -0700 Quanah Gibson-Mount <qua...@zimbra.com> wrote: Just curious -- Any update on this? Is OpenSSL going to use something GPLv2 compatible? etc. Thanks, Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Friday, November 20, 2015 7:34 PM + "Salz, Rich" <rs...@akamai.com> wrote: It's almost definitely going to be Apache v2. Is there a possibility of releasing it under more than one license? Otherwise, I honestly don't really see the point of relicensing OpenSSL as moving to apache v2 does not resolve the primary problem with the OpenSSL license that currently exists. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Friday, November 20, 2015 9:47 PM +0100 Richard Levitte <levi...@openssl.org> wrote: I would like to point out that the GNU project talks about the Apache v2 license in positive terms: http://www.gnu.org/licenses/license-list.html When dealing with the GPLv3, yes. However, it clearly notes the incompatibility with the GPLv2. Moving to a license that does not resolve the GPLv2 compatibility problem really doesn't help. I guess the overwhelming feedback from the community that the new license really needs to be GPLv2 compatible just went in one eye and out the other, so to speak. Re: Rich, yes removing the advertising clause is helpful, etc. Just move to plain BSD/MIT license then, and resolve all the issues. Or, does the community input that was received, that was consistently pointing out that a non-GPLv2 compatible license does not solve the fundamental problems with the current license going to continue to be blatantly ignored? --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Friday, November 20, 2015 9:28 PM + Jonathan Larmour <j...@ecoscentric.com> wrote: So a dual license still seems desirable to me. However, also, and as I said when this came up before, I don't believe the OpenSSL team is legally permitted to change the license as they do not hold the entire copyright. To change the licence, you need a copyright assignment or Contributor License Agreement from every individual or company who has contributed code to OpenSSL. You cannot change the terms of something you do not own. That is admittedly a significant hurdle to any change. Perhaps contributors, when approached by OpenSSL, can simly say they will not release their rights unless the project adopts a truly open license in the spirit of the original BSD style license minus the advertising clause. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Mailman version used by OpenSSL is misconfigured and/or broken in relation to DKIM
--On Tuesday, August 18, 2015 11:30 AM +0200 Kurt Roeckx k...@roeckx.be wrote: On Mon, Aug 17, 2015 at 10:55:53AM -0700, Quanah Gibson-Mount wrote: However, there are two solutions to that allow adding a footer when list subscribers may have DKIM signed email: a) As noted in the OpenDKIM README, in the Mailing Lists section, if the list traffic is itself has DKIM signing in place, it will override the DKIM signing done by the sender. This allows the footer modification to the message to no longer be an issue. This fixed the DKIM problem, not the DMARC issue. For DMARC the signature should come from the same as the From address. Since SPF is going to fail with your From, the receiver will need to see DKIM that matches the From. For DMARC either SPF or DKIM should be valid and match the From field, while for SPF and DKIM itself the From doesn't matter. So really the only options for DMARC are: - Do not touch either the signed headers or body at all, leave From intact, keep the DKIM signatures. But even then it might break. - Change the From. You can leave the DKIM signature in tact or remove it, it doesn't change anything. I think option #3 here: https://dmarc.org/wiki/FAQ#I_operate_a_mailing_list_and_I_want_to_interoperate_with_DMARC.2C_what_should_I_do.3F would be the solution? --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Mailman version used by OpenSSL is misconfigured and/or broken in relation to DKIM
--On Wednesday, August 05, 2015 5:54 PM +0200 Kurt Roeckx k...@roeckx.be wrote: On Wed, Aug 05, 2015 at 06:54:33AM -0700, Quanah Gibson-Mount wrote: Yesterday, I was alerted by a member of the list that my emails to openssl-dev are ending up in their SPAM folder. After examining my emails as sent out by OpenSSL's mailman, I saw that it is mucking with the headers, causing DKIM failures. This could be because of one of two reasons: a) The version of mailman used by the OpenSSL project (2.1.18) has a known bug around DKIM that was fixed in 2.1.19 That seems to be about wrapped messages in case of moderation? Ok, good to know, not applicable here then. ;) b) The mailman configuration is incorrect. You mean things like: - We change the subject to include the list name? I've fixed our config to no longer sign the subject header. - We add a footer about the list? Yes, this is definitely a problem, since it screws with the body. Personally, I don't see the point of the openssl-dev footer. If someone's on the list, I would hope they're smart enough to figure out how to unsubscribe (although sadly, I see time and again on other lists where people aren't...). However, there are two solutions to that allow adding a footer when list subscribers may have DKIM signed email: a) As noted in the OpenDKIM README, in the Mailing Lists section, if the list traffic is itself has DKIM signing in place, it will override the DKIM signing done by the sender. This allows the footer modification to the message to no longer be an issue. b) Mailman can be configured to strip DKIM headers entirely from incoming email. This is generally considered bad practice, but it does allow the emails to get delivered to all list members w/o issue. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Mailman version used by OpenSSL is misconfigured and/or broken in relation to DKIM
Yesterday, I was alerted by a member of the list that my emails to openssl-dev are ending up in their SPAM folder. After examining my emails as sent out by OpenSSL's mailman, I saw that it is mucking with the headers, causing DKIM failures. This could be because of one of two reasons: a) The version of mailman used by the OpenSSL project (2.1.18) has a known bug around DKIM that was fixed in 2.1.19 b) The mailman configuration is incorrect. I attempted to file an RT to alert the OpenSSL project of this significant issue. Unfortunately, I received the following grossly uneducated response. Can someone who actually understands email, and why it is critical that DKIM signed messages sent from list members *NOT* be broken by OpenSSL's mailman instance please educate whomever the moderator is on this? Personally I'd nominate Viktor for that activity. And then, can someone please fix this issue? :) Error is: Authentication-Results: edge01.zimbra.com (amavisd-new); dkim=fail (1024-bit key) reason=fail (message has been altered) header.d=zimbra.com Thanks! --Quanah Forwarded Message Date: Wednesday, August 05, 2015 2:19 AM + From: openssl-bugs-mod-ow...@openssl.org To: qua...@zimbra.com Subject: Request to mailing list openssl-bugs-mod rejected Your request to the openssl-bugs-mod mailing list Posting of your message titled mailman version and/or configuration for the openssl-dev list breaks DKIM has been rejected by the list moderator. The moderator gave the following reason for rejecting your request: This is not a bug. We're not really interested in DKIM FWIW. Any questions or comments should be directed to the list administrator at: openssl-bugs-mod-ow...@openssl.org -- End Forwarded Message -- -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Tuesday, August 04, 2015 2:14 PM -0400 Brian Smith br...@briansmith.org wrote: It is natural for a lawyer to tell you to require lots of things to protect whatever entity is paying them. That's defense-in-depth type advice from them. However, lawyers do cost-benefit analysis based on the goals you give them. If you tell them that avoiding CLAs is important then they'll help you avoid CLAs, generally. I'll second this -- At Zimbra, I went through this recently with our legal team, as we are working to make it much simpler for the community to contribute back. Initially the legal team proposed a CLA. I spent a significant amount of time explaining why this was problematic, and they eventually agreed that an IPR similar to the one I noted for OpenLDAP was sufficient for our case. There of course could be reasons why a CLA would be necessary for the OpenSSL project, but nothing comes immediately to my mind as to why that'd be the case. CLA's just generally seem to be the default starting position with legal teams, in my experience. ;) --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] We're working on license changes
--On Friday, July 31, 2015 3:19 PM -0400 Brian Smith br...@briansmith.org wrote: On Fri, Jul 31, 2015 at 12:29 PM, Hanno Böck ha...@hboeck.de wrote: Salz, Rich rs...@akamai.com wrote: In the spirit of making OpenSSL as useful as possible for everyone I would consider a permissive license that's more compatible (e.g. MIT) a wiser choice. I agree 100%. What is wrong with the ISC-style license that LibreSSL and BoringSSL have been using to share code? Why not use that same license for new code? The ability to share code between these projects is hugely valuable, especially when it comes to getting security problems fixed in a timely and secure manner. Also, I question the need for people to sign a CLA to contribute to OpenSSL. OpenSSL has been very successful for decades without a CLA requirement. Lots of other projects are extremely successful without a CLA. A CLA seems unnecessary. +1 It is curious as well that the openssl project did not solicit feedback from it's community before announcing said license change to see what the general consensus of the community is on the best path forward, and instead is moving towards a significantly more restrictive license than what OpenSSL was previously offered under. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3857] hash files for validating source are incorrectly formed
The hash files (md5, sha1) for validating downloaded source are not correclty formed, breaking the check (-c) function: wget https://www.openssl.org/source/openssl-1.0.1m.tar.gz wget https://www.openssl.org/source/openssl-1.0.1m.tar.gz.sha1 build@c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ sha1sum -c openssl-1.0.1m.tar.gz.sha1 sha1sum: openssl-1.0.1m.tar.gz.sha1: no properly formatted SHA1 checksum lines found build@c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ cat openssl-1.0.1m.tar.gz.sha1 4ccaf6e505529652f9fdafa01d1d8300bd9f3179 Now, to have it correctly formatted: build@c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ sha1sum openssl-1.0.1m.tar.gz openssl-1.0.1m.tar.gz.sha1 build@c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ cat openssl-1.0.1m.tar.gz.sha1 4ccaf6e505529652f9fdafa01d1d8300bd9f3179 openssl-1.0.1m.tar.gz build@c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ sha1sum -c openssl-1.0.1m.tar.gz.sha1 openssl-1.0.1m.tar.gz: OK --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] deadlock issue with OpenSSL 1.0.1j
We've been seeing a problem with openssl deadlocking in the 1.0.1j release that didn't occur in previous releases. I've looked over the change log fixes for the k, l, and m releases, but I haven't seen anything that appears to resolve a deadlock problem. Does anyone know of such an issue that was released since 1.0.1j? Thanks! --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server
--On Wednesday, March 25, 2015 12:01 AM +0100 Kurt Roeckx via RT r...@openssl.org wrote: On Tue, Mar 24, 2015 at 10:09:18PM +0100, Salz, Rich via RT wrote: The short answer is that nobody has come up with comprehensive cross-platform IPv6 support. Fixing the apps isn't enough; how does a server listen on IPv4, v6, both -- and make it work on our supported platforms? What should the various BIO API's do? Please note that I actually have a patch that does all that. I also said not to actually submit this patch. Where can one obtain your patch from? When will it be integrated into OpenSSL? Do you have a version of your patch that works with the 1.0.1 series? --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server
--On Wednesday, March 25, 2015 12:01 AM +0100 Kurt Roeckx via RT r...@openssl.org wrote: On Tue, Mar 24, 2015 at 10:09:18PM +0100, Salz, Rich via RT wrote: The short answer is that nobody has come up with comprehensive cross-platform IPv6 support. Fixing the apps isn't enough; how does a server listen on IPv4, v6, both -- and make it work on our supported platforms? What should the various BIO API's do? Please note that I actually have a patch that does all that. I also said not to actually submit this patch. Where can one obtain your patch from? When will it be integrated into OpenSSL? Do you have a version of your patch that works with the 1.0.1 series? --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server
--On Tuesday, March 24, 2015 9:29 PM + Short, Todd tsh...@akamai.com wrote: I was unaware of 2501. But that's fine by me… however, why hasn't 2051 been applied to the code? People have been asking this question for years. https://lwn.net/Articles/486369/ http://openssl.6102.n7.nabble.com/Openssl-IPv6-Support-td54588.html Here's an even *older* RT from 2006: http://rt.openssl.org/Ticket/Display.html?id=1365user=guestpass=guest There's never been any sort of real substantive answer as to why getting IPv6 support in has taken almost a decade, when people have constantly supplied patches for it. Supposedly it was going to go into 1.0.2. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server
--On Tuesday, March 24, 2015 9:29 PM + Short, Todd tsh...@akamai.com wrote: I was unaware of 2501. But that's fine by me… however, why hasn't 2051 been applied to the code? People have been asking this question for years. https://lwn.net/Articles/486369/ http://openssl.6102.n7.nabble.com/Openssl-IPv6-Support-td54588.html Here's an even *older* RT from 2006: http://rt.openssl.org/Ticket/Display.html?id=1365user=guestpass=guest There's never been any sort of real substantive answer as to why getting IPv6 support in has taken almost a decade, when people have constantly supplied patches for it. Supposedly it was going to go into 1.0.2. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server
--On Tuesday, March 03, 2015 3:15 PM -0600 Short, Todd tsh...@akamai.com wrote: The previous patch file had two bugs due to a swapped argument and the formatting changes (missing braces). The attached is an updated patch. Why did you open a new RT when http://rt.openssl.org/Ticket/Display.html?id=2051 already exists and has for ages? I would suggest RT3717 be marked as a duplicate of 2051. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3717] Patch for IPv6 support in s_client/s_server
--On Tuesday, March 03, 2015 3:15 PM -0600 Short, Todd tsh...@akamai.com wrote: The previous patch file had two bugs due to a swapped argument and the formatting changes (missing braces). The attached is an updated patch. Why did you open a new RT when http://rt.openssl.org/Ticket/Display.html?id=2051 already exists and has for ages? I would suggest RT3717 be marked as a duplicate of 2051. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] invalid certificate setup for mta.opensslfoundation.net
Kind of humorous that I get cert errors when connecting to https://mta.opensslfoundation.net/ URLs. The cert itself looks to be very poorly formed (like someone who doesn't understand how to create certs set it up). Cert information: CN: mta O: NONE OU: NONE Issued by: CN: mta O: mta OU: NONE --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration ___ openssl-dev mailing list openssl-dev@openssl.org https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev
Re: [openssl.org #2665] s_client support for starttls ldap
--On November 14, 2014 at 1:30:10 AM + Viktor Dukhovni openssl-us...@dukhovni.org wrote: On Thu, Nov 13, 2014 at 04:57:25PM -0800, Quanah Gibson-Mount wrote: It would be cool to have the Net::SSLeay code as well, however, for other tests I'd like to set up. Attached. You'll need a sufficiently recent Net::SSLeay, build from CPAN if the packaged one is too old on your system. Thanks! I pulled in the patch that has OpenLDAP log the protocol cipher on the server side, so having the client side info will fill out the rest of what I need. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2665] s_client support for starttls ldap
Like it or not, s_client is generally the de facto tool for testing starttls via the openssl command line. In addition, the work to add support for startTLS and ldap is rather trivial, and has already been done: https://groups.google.com/forum/#!topic/mailing.openssl.users/1OOwXp45iIw It would be invaluable to have this support in OpenSSL to admins around the world. This subject comes up repeatedly because people expect it to work. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2665] s_client support for starttls ldap
--On November 13, 2014 at 5:45:22 PM + Viktor Dukhovni openssl-us...@dukhovni.org wrote: Personally, I would prefer to see support for reporting TLS features of LDAP servers as a verbosity feature in ldapsearch or similar. It's already scheduled to go into OpenLDAP. Can't talk for other LDAP projects. I.e., it'll definitely be part of OpenLDAP 2.5 and later. I'll be discussing with the other OpenLDAP folks if we can put it into 2.4.41 as well. However, not everyone uses the ldapsearch from OpenLDAP, so it doesn't solve the problem in general. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Openssl IPv6 Support
--On November 5, 2014 at 10:10:26 AM +0100 Marcus Meissner meiss...@suse.de wrote: On Wed, Nov 05, 2014 at 08:28:40AM +, Mody, Darshan (Darshan) wrote: Hi, Does Openssl support IPv6 officially?. AFAIK the libssl and libcrypto libraries do not use sockets at all, these are left to the applications/libraries using them. So openssl does neither support ipv4 nor ipv6. apparently you've never used s_client, or looked at the *ancient* bug explicitly asking that IPv6 support be added for s_client s_server in OpenSSL. It even has a patch that's been widely used for years by major linux distributions. It boggles the mind that to this day that patch has not been integrated in the 5 years since the bug was opened. See http://rt.openssl.org/Ticket/Display.html?id=2051, https://bugs.debian.org/589520 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: misleading outdated comment
--On Thursday, October 30, 2014 10:00 PM +0100 pl p...@artisanlogiciel.net wrote: Hi, First of all this is my first post here, i then expect from you some forgiveness. I am a heavy user of openssl library. I try to add some information into http://wiki.opensslfoundation.com at my level to add my little cents. This post is really a minor detail, but - given code is not largely documented - i would expect comments even minor to be accurate. in ssl_lib.c line 2829 i read : /* For the next 2 functions, SSL_clear() sets shutdown and so * one of these calls will reset it */ functions are : void SSL_set_accept_state(SSL *s) and void SSL_set_connect_state(SSL *s) I think comment can be removed or should be reviewed since looking in code s-shutdown is actualy cleared correctly by SSL_clear(), so if it should be reset to 0 it is not due to SSL_clear(). neither void ssl2_clear(SSL *s) void ssl3_clear(SSL *s) void tls1_clear(SSL *s) void dtls1_clear(SSL *s) seems to modify shutdown field either. And looking in git, this is not new : commit 413c4f45 that resets it to 0 in SSL_clear() is 1999-02-16 10:22:21. So this comment is really obsolete, outdated and misleading. Regards, Philippe Lhardy Bugs should be reported via the bug tracker, as noted at: https://www.openssl.org/support/rt.html --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Odd behavior out of openssl 1.0.1h
After upgrading to OpenSSL 1.0.1h, I've found now that when initiating startTLS connections to a system linked to OpenSSL 1.0.1h, it always tries to do certificate auth with the client. This causes a lot of failures, for example with postfix. I.e., I initiate a connection to port 587 on the postfix server with startTLS. Before I even get to the stage of authenticating as a user, it tries SSL cert auth, and drops the client due to unknown CA, which, if I were trying to do cert auth would make sense, but I'm not trying to do cert auth at all, I'm just trying to connect to the port. Is this a known bug in 1.0.1h? Any suggestions on how to turn off this sudden new bit to always try cert auth, regardless of whether or not it is desired? Thanks! --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Odd behavior out of openssl 1.0.1h
--On Monday, June 30, 2014 3:58 PM -0700 Quanah Gibson-Mount qua...@zimbra.com wrote: After upgrading to OpenSSL 1.0.1h, I've found now that when initiating startTLS connections to a system linked to OpenSSL 1.0.1h, it always tries to do certificate auth with the client. This causes a lot of failures, for example with postfix. Never mind, I tracked it down to an oddity with the Perl module I am using. ;) --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3381] Typo in macro name for ASN (1.0.1h)
--On Sunday, June 08, 2014 11:57 PM +0200 Matt Caswell via RT r...@openssl.org wrote: Hi Quanah Thanks for the submission. The problem with correcting this is that technically it forms part of the public API (since the macro is defined in asn1.h). I guess there's probably not a huge risk in changing it, as I can't imagine there's too many people relying on that define being there, but then on the other hand as this is just a minor cosmetic change its probably not worth it. I note that this has been spotted before and that the decision then was to just correct the error string itself (and not the macro name) - see commit 2b4ffc6. I think that's a reasonable compromise, so I'll stick with that decision and not make any further corrections. It could be fixed for 1.0.2 however, right? It's reasonable to expect the API to change across major releases. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3381] Typo in macro name for ASN (1.0.1h)
--On Sunday, June 08, 2014 11:57 PM +0200 Matt Caswell via RT r...@openssl.org wrote: Hi Quanah Thanks for the submission. The problem with correcting this is that technically it forms part of the public API (since the macro is defined in asn1.h). I guess there's probably not a huge risk in changing it, as I can't imagine there's too many people relying on that define being there, but then on the other hand as this is just a minor cosmetic change its probably not worth it. I note that this has been spotted before and that the decision then was to just correct the error string itself (and not the macro name) - see commit 2b4ffc6. I think that's a reasonable compromise, so I'll stick with that decision and not make any further corrections. It could be fixed for 1.0.2 however, right? It's reasonable to expect the API to change across major releases. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3381] Typo in macro name for ASN (1.0.1h)
ASN1_R_UNKOWN_FORMAT should be ASN1_R_UNKNOWN_FORMAT:
./crypto/asn1/asn1_err.c:{ERR_REASON(ASN1_R_UNKOWN_FORMAT),unknown
format},
./crypto/asn1/asn1_gen.c: ASN1err(ASN1_F_ASN1_CB,
ASN1_R_UNKOWN_FORMAT);
./crypto/asn1/asn1.h:#define ASN1_R_UNKOWN_FORMAT
195
--Quanah
--
Quanah Gibson-Mount
Server Architect
Zimbra, Inc.
Zimbra :: the leader in open source messaging and collaboration
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #3376] 0.9.8za/1.0.0m/1.0.1h build failure in ssl/s3_pkt.c - missing include for limits.h
--On Thursday, June 05, 2014 4:33 PM -0400 Ray Satiro raysat...@yahoo.com wrote: I think maybe he just added it twice because it is missing. I noticed the same thing when I tried to build this afternoon. Definitely wasn't added twice, you can see it is native to openssl-1.0.1h. In fact, it didn't use to be a part of 1.0.1: diff -ru openssl-1.0.1f/ssl/s3_pkt.c openssl-1.0.1h/ssl/s3_pkt.c --- openssl-1.0.1f/ssl/s3_pkt.c 2014-01-06 07:47:42.0 -0600 +++ openssl-1.0.1h/ssl/s3_pkt.c 2014-06-05 04:44:33.0 -0500 @@ -110,6 +110,7 @@ */ #include stdio.h +#include limits.h #include errno.h #define USE_SOCKETS #include ssl_locl.h --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenLDAP: slapi contrib overlays
I would suggest you email the openldap-techni...@openldap.org list and not the openssl Dev list. --Quanah --On March 3, 2014 at 2:38:11 PM + Sergio NNX sfhac...@hotmail.com wrote: Hi, I've building OpenLDAP 2.4.39 from source under MinGW. A couple of questions: a) I added '--enable-slapi' to configure. I got a few compilation errors. Is slapi Windows ready? b) I added some contrib modules (e.g. allop, lastbind, etc) and tried to link them statically. Compilation and linking woked OK. Then, I type: slapd -VVV and I expect to see those contrib modules listed under the overlay section. None of them appear. I added 'overlay allop' to slapd.conf, but when slapd starts, I get: 5314932d overlay allop not found 5314932d ..\etc\openldap\slapd.conf: line 30: overlay handler exited with 1! Can anyone point me to the right direction? Thanks in advance. Ciao, Sergio. -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Makefile.org: enclose CC parameter passing in quotes
--On Monday, January 13, 2014 3:41 PM -0300 Gustavo Zacarias gust...@zacarias.com.ar wrote: The compiler invocation might contain a space for example when using ccache. Duplicate of [openssl.org #3232] [PATCH] Makefile.org: Fix usage of CC=gcc -m32 --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2051] [PATCH] IPv6 support for s_client and s_server
--On Thursday, April 11, 2013 9:37 AM -0700 Dan Mahoney, System Admin d...@prime.gushi.org wrote: I would love it if the maintainers would actually come forward and give a direct answer on whether or not they're interested. +1 --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: 1.0.1d broke startTLS with LDAP
--On Thursday, February 07, 2013 11:43 PM +0100 Andy Polyakov ap...@openssl.org wrote: After rebuilding my OpenLDAP servers against 1.0.1d, my perl scripts can no longer negotiate startTLS with the OpenLDAP server, and hang infinitely. This is a major regression vs 1.0.1c. It's more than likely to be same issue discussed in Major OpenSSL 1.0.1d regression from 1.0.1c and ticket #2975. As Steve mentioned in ticket #2975, verify http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=32cc247. I can confirm this fix resolves the issue I encountered. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
1.0.1d broke startTLS with LDAP
After rebuilding my OpenLDAP servers against 1.0.1d, my perl scripts can no longer negotiate startTLS with the OpenLDAP server, and hang infinitely. This is a major regression vs 1.0.1c. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2905] Double locking bug added in openssl-1.0.0h crypto/asn1/x_pubkey.c
--On Monday, November 05, 2012 2:55 PM +0100 Richard Skinner via RT r...@openssl.org wrote: The following code added in 1.0.0h causes CRYPTO_LOCK_EVP_PKEY lock to be requested twice with no intervening unlock when there is a race between 2 or more threads to create the EVP_PKEY associated with the X509_PUBKEY. The second lock request occurs in EVP_PKEY_free(). crypto/asn1/x_pubkey.c:174 Duplicate of RT #2866? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2891] deadlock in X509_PUBKEY_get without recursive mutexes
--On Wednesday, October 03, 2012 10:41 AM +0200 Ben Hendrickson via RT r...@openssl.org wrote: I am using openssl-1.0.1c, and found a deadlock when using the library. In function X509_PUBKEY_get (xpubkey.c:175) it locks CRYPTO_LOCK_EVP_PKEY. Three lines later (so xpubkey.c:178), it calls EVP_PKEY_free which also locks CRYPTO_LOCK_EVP_PKEY (p_lib.c: 393). This behavior is fine if the user is providing OpenSSL with recursive mutexes, but I gather from the example code mttest.c that recursive mutexes are not required, as it creates non-recursive pthread mutexes. Here is a callstack from a deadlocked thread at this point (codulus::SSLLockingCallback is my user provided locking callback): # 5 0x0044b1eb in codulus::SSLLockingCallback (mode=9, type=10, file=0x68eead p_lib.c, line=393) at ../..//util/ssl.cc:19 # 6 0x0045f198 in CRYPTO_add_lock () # 7 0x004d0687 in EVP_PKEY_free () # 8 0x005ff020 in X509_PUBKEY_get () # 9 0x004e5c01 in internal_verify () # 10 0x004e65bf in X509_verify_cert () # 11 0x00472720 in ssl_verify_cert_chain () # 12 0x00507d7b in ssl3_get_server_certificate () # 13 0x0050c184 in ssl3_connect () # 14 0x00465d87 in ssl23_connect () # 15 0x00466741 in ssl23_write () Dupe of 2866? --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1c deadlock
--On Wednesday, September 05, 2012 3:14 PM -0400 Bodo Moeller bmoel...@acm.org wrote: On Wed, Sep 5, 2012 at 3:06 PM, Bodo Moeller bmoel...@acm.org wrote: We've managed on a few occasions now to reproduce an issue where OpenSSL deadlocks while trying to acquire a mutex it already has. I filed http://rt.openssl.org/Ticket/Display.html?id=2866 about this issue. I currently have a server where this has occurred, with the process in GDB. However, the team that owns the server needs it back, so I wanted to know if there is anything further the dev team would like me to gather from the process before I drop out of GDB. So far we've encountered this issue on both SLES11 SP2 and Ubuntu 12 LTS linux distributions. Thanks -- I've managed to find the buggy code (crypto/asn1/x_pubkey.c calls EVP_PKEY_free(ret) while holding lock CRYPTO_LOCK_EVP_PKEY, but EVP_PKEY_free(ret) always tries to obtain that lock first). Will patch this in a moment. Actually I see this has been fixed already -- please try the latest 1.0.0 snapshot to confirm: http://cvs.openssl.org/chngview?cn=22572 Yes, I've rebuilt with this patch in place. ;) However, it was extremely difficult to trigger (2 times in 4 weeks of heavy testing), so it is difficult for me to prove conclusively if this fixes it or not, although I agree the code inspection implies it is fixed. ;) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL 1.0.1c deadlock
Hi, We've managed on a few occasions now to reproduce an issue where OpenSSL deadlocks while trying to acquire a mutex it already has. I filed http://rt.openssl.org/Ticket/Display.html?id=2866 about this issue. I currently have a server where this has occurred, with the process in GDB. However, the team that owns the server needs it back, so I wanted to know if there is anything further the dev team would like me to gather from the process before I drop out of GDB. So far we've encountered this issue on both SLES11 SP2 and Ubuntu 12 LTS linux distributions. Thanks, Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. Zimbra :: the leader in open source messaging and collaboration __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2866] Openssl can deadlock OpenSSL version 1.0.1c
--On Tuesday, September 04, 2012 10:26 PM +0200 Stephen Henson via RT
r...@openssl.org wrote:
[qua...@zimbra.com - Tue Aug 28 22:43:34 2012]:
--On Tuesday, August 28, 2012 4:36 PM +0200 The default queue via RT
r...@openssl.org wrote:
Mutex information from gdb:
(gdb) print mutex
$5 = (ldap_pvt_thread_mutex_t *) 0x7f8387626f30
(gdb) print *mutex
$6 = {__data = {__lock = 2, __count = 0, __owner = 23352, __nusers = 1,
__kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = \002\000\000\000\000\000\000\000\070[\000\000\001, '\000'
repeats 26 times, __align = 2}
Can you provide a stack trace when you get the deadlock?
Hi Stephen,
The first comment is a full stack trace. Did you download it from RT?
http://rt.openssl.org/Ticket/Attachment/34714/18567/
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2866] Openssl can deadlock OpenSSL version 1.0.1c
--On Wednesday, September 05, 2012 12:40 AM +0200 Dr. Stephen Henson
st...@openssl.org wrote:
On Tue, Sep 04, 2012, Quanah Gibson-Mount via RT wrote:
--On Tuesday, September 04, 2012 10:26 PM +0200 Stephen Henson via RT
r...@openssl.org wrote:
[qua...@zimbra.com - Tue Aug 28 22:43:34 2012]:
--On Tuesday, August 28, 2012 4:36 PM +0200 The default queue via RT
r...@openssl.org wrote:
Mutex information from gdb:
(gdb) print mutex
$5 = (ldap_pvt_thread_mutex_t *) 0x7f8387626f30
(gdb) print *mutex
$6 = {__data = {__lock = 2, __count = 0, __owner = 23352, __nusers =
1, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = \002\000\000\000\000\000\000\000\070[\000\000\001, '\000'
repeats 26 times, __align = 2}
Can you provide a stack trace when you get the deadlock?
Hi Stephen,
The first comment is a full stack trace. Did you download it from RT?
http://rt.openssl.org/Ticket/Attachment/34714/18567/
See if this fixes it:
http://cvs.openssl.org/chngview?cn=22570
Thanks! I'll rebuild with this patch and see if we can trigger it. It has
been difficult to force to happen (Only twice in our test environment under
heavy load in the span of 4 weeks).
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
Re: [openssl.org #2866] AutoReply: Openssl can deadlock OpenSSL version 1.0.1c
--On Tuesday, August 28, 2012 4:36 PM +0200 The default queue via RT
r...@openssl.org wrote:
Mutex information from gdb:
(gdb) print mutex
$5 = (ldap_pvt_thread_mutex_t *) 0x7f8387626f30
(gdb) print *mutex
$6 = {__data = {__lock = 2, __count = 0, __owner = 23352, __nusers = 1,
__kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}},
__size = \002\000\000\000\000\000\000\000\070[\000\000\001, '\000'
repeats 26 times, __align = 2}
--Quanah
--
Quanah Gibson-Mount
Sr. Member of Technical Staff
Zimbra, Inc
A Division of VMware, Inc.
Zimbra :: the leader in open source messaging and collaboration
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
