Re: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible
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 signature.asc Description: OpenPGP digital signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] The new OpenSSL license should be made GPLv2 compatible
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. signature.asc Description: OpenPGP digital signature -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: OpenSSL has exploit mitigation countermeasures to make sure its exploitable
On 10/04/14 18:46, Salz, Rich wrote: We've been compiling -DOPENSSL_NO_BUF_FREELISTS forever. Our only complaint is that the BUF is misspelled :) Theo can be obnoxious. This should not be news to most folks. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA Probably this blog post provides more information about what Akamai has been doing related to this issue: https://blogs.akamai.com/2014/04/heartbleed-update.html It would be appreciated if you cared to contribute back your own custom secure_malloc allocator. signature.asc Description: OpenPGP digital signature
OpenSSL has exploit mitigation countermeasures to make sure its exploitable
OpenSSL has exploit mitigation countermeasures to make sure its exploitable http://article.gmane.org/gmane.os.openbsd.misc/211963 Leaving aside the personal (and questionable) opinions from Theo about OpenSSL developers, I think he is right about that this malloc wrapper looks quite bad. Probably without it the heartbleed bug won't have caused so much havoc, or would have been detected earlier by some debugger. What's the stance of openssl developers on this? Will you get rid of this wrapper? Regards! signature.asc Description: OpenPGP digital signature
[openssl.org #2860] [PATCH 0/4] Improve XMPP protocol support for starttls on s_client
This serie of patches improves the xmpp protocol support for starttls on s_client. This fixes several issues found on the code related to xmpp protocol, and also adds a new option that allows to start the tls session with any server that uses virtual hosts (like gtalk). * The following tests now stablish the TLS connection correctly, meanwhile before this patch they failed: openssl s_client -connect coderollers.com:5222 -starttls xmpp openssl s_client -connect chat.facebook.com:5222 -starttls xmpp openssl s_client -connect talk.google.com:5222 -starttls xmpp -xmpphost gmail.com * Also, the following test now fails properly, meanwhile before this patch it generated an infinite loop: openssl s_client -connect random.jabb3r.net:5222 -starttls xmpp Carlos Alberto Lopez Perez (4): Fix XMPP code detection on s_client starttls xmpp Fix infinite loop on s_client starttls xmpp Add xmpp to the list of supported starttls protocols on s_client manpage Add an -xmpphost option to s_client apps/s_client.c | 17 + doc/apps/s_client.pod | 10 +- 2 files changed, 22 insertions(+), 5 deletions(-) -- 1.7.10.4 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2860] [PATCH 1/4] Fix XMPP code detection on s_client starttls xmpp
* Some XMPP Servers (OpenFire) use double quotes.
* This makes s_client starttls work with this servers.
* Tested with OpenFire servers from http://xmpp.net/ ::
openssl s_client -connect coderollers.com:5222 -starttls xmpp
---
apps/s_client.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/apps/s_client.c b/apps/s_client.c
index 783a49e..b5dcde5 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -1551,7 +1551,8 @@ SSL_set_tlsext_status_ids(con, ids);
xmlns='jabber:client' to='%s' version='1.0', host);
seen = BIO_read(sbio,mbuf,BUFSIZZ);
mbuf[seen] = 0;
- while (!strstr(mbuf, starttls
xmlns='urn:ietf:params:xml:ns:xmpp-tls'))
+ while (!strstr(mbuf, starttls
xmlns='urn:ietf:params:xml:ns:xmpp-tls')
+ !strstr(mbuf, starttls
xmlns=\urn:ietf:params:xml:ns:xmpp-tls\))
{
if (strstr(mbuf, /stream:features))
goto shut;
--
1.7.10.4
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #2860] [PATCH 2/4] Fix infinite loop on s_client starttls xmpp
* When the host used in -connect is not what the remote XMPP server expects
the server will return an error like this:
stream:error
host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/
/stream:error
* But the actual code will stay on the loop forever because the stop condition
/stream:features will never happen,
* Make this more robust: The stop condition should be that BIO_read failed
* Test if for example with ::
openssl s_client -connect random.jabb3r.net:5222 -starttls xmpp
---
apps/s_client.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/apps/s_client.c b/apps/s_client.c
index b5dcde5..982794c 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -1554,9 +1554,11 @@ SSL_set_tlsext_status_ids(con, ids);
while (!strstr(mbuf, starttls
xmlns='urn:ietf:params:xml:ns:xmpp-tls')
!strstr(mbuf, starttls
xmlns=\urn:ietf:params:xml:ns:xmpp-tls\))
{
- if (strstr(mbuf, /stream:features))
- goto shut;
seen = BIO_read(sbio,mbuf,BUFSIZZ);
+
+ if (seen = 0)
+ goto shut;
+
mbuf[seen] = 0;
}
BIO_printf(sbio, starttls
xmlns='urn:ietf:params:xml:ns:xmpp-tls'/);
--
1.7.10.4
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
[openssl.org #2860] [PATCH 3/4] Add xmpp to the list of supported starttls protocols on s_client manpage
--- doc/apps/s_client.pod |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/apps/s_client.pod b/doc/apps/s_client.pod index 4ebf7b5..7849c3e 100644 --- a/doc/apps/s_client.pod +++ b/doc/apps/s_client.pod @@ -203,7 +203,7 @@ command for more information. send the protocol-specific message(s) to switch to TLS for communication. Bprotocol is a keyword for the intended protocol. Currently, the only -supported keywords are smtp, pop3, imap, and ftp. +supported keywords are smtp, pop3, imap, ftp and xmpp. =item B-tlsextdebug -- 1.7.10.4 __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2860] [PATCH 4/4] Add an -xmpphost option to s_client
* Many XMPP servers are configured with multiple domains (virtual hosts)
* In order to establish successfully the TLS connection you have to specify
which virtual host you are trying to connect.
* Test this, for example with ::
* Fail:
openssl s_client -connect talk.google.com:5222 -starttls xmpp
* Works:
openssl s_client -connect talk.google.com:5222 -starttls xmpp -xmpphost
gmail.com
---
apps/s_client.c |8 +++-
doc/apps/s_client.pod |8
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/apps/s_client.c b/apps/s_client.c
index 982794c..40a5efe 100644
--- a/apps/s_client.c
+++ b/apps/s_client.c
@@ -572,6 +572,7 @@ int MAIN(int argc, char **argv)
short port=PORT;
int full_log=1;
char *host=SSL_HOST_NAME;
+ char *xmpphost = NULL;
char *cert_file=NULL,*key_file=NULL;
int cert_format = FORMAT_PEM, key_format = FORMAT_PEM;
char *passarg = NULL, *pass = NULL;
@@ -683,6 +684,11 @@ int MAIN(int argc, char **argv)
if (!extract_host_port(*(++argv),host,NULL,port))
goto bad;
}
+ else if (strcmp(*argv,-xmpphost) == 0)
+ {
+ if (--argc 1) goto bad;
+ xmpphost= *(++argv);
+ }
else if (strcmp(*argv,-verify) == 0)
{
verify=SSL_VERIFY_PEER;
@@ -1548,7 +1554,7 @@ SSL_set_tlsext_status_ids(con, ids);
int seen = 0;
BIO_printf(sbio,stream:stream
xmlns:stream='http://etherx.jabber.org/streams'
- xmlns='jabber:client' to='%s' version='1.0', host);
+ xmlns='jabber:client' to='%s' version='1.0', xmpphost?
xmpphost:host);
seen = BIO_read(sbio,mbuf,BUFSIZZ);
mbuf[seen] = 0;
while (!strstr(mbuf, starttls
xmlns='urn:ietf:params:xml:ns:xmpp-tls')
diff --git a/doc/apps/s_client.pod b/doc/apps/s_client.pod
index 7849c3e..2489cf5 100644
--- a/doc/apps/s_client.pod
+++ b/doc/apps/s_client.pod
@@ -37,6 +37,7 @@ Bopenssl Bs_client
[B-bugs]
[B-cipher cipherlist]
[B-starttls protocol]
+[B-xmpphost hostname]
[B-engine id]
[B-tlsextdebug]
[B-no_ticket]
@@ -205,6 +206,13 @@ send the protocol-specific message(s) to switch to TLS for
communication.
Bprotocol is a keyword for the intended protocol. Currently, the only
supported keywords are smtp, pop3, imap, ftp and xmpp.
+=item B-xmpphost hostname
+
+This option, when used with -starttls xmpp, specifies the host for the
+to attribute of the stream element.
+If this option is not specified, then the host specified with -connect
+will be used.
+
=item B-tlsextdebug
print out a hex dump of any TLS extensions received from the server.
--
1.7.10.4
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
