Compatibility with OpenSSL 1.1

[rhertzog]

Debian wants to switch to OpenSSL 1.1 and uwsgi is currently failing to build with that version as reported in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828590

It would be nice if uwsgi could be made to work with OpenSSL 1.1 too.

[xrmx]

Thanks for forwarding the issue here, will take a look.

[xrmx]

@unbit i think we have a problem, you poked with struct internals which have now made opaque and thus we no more access to. With the untested patch above these two hunks needs a rework:

core/ssl.c: In function ‘uwsgi_ssl_info_cb’:
core/ssl.c:28:24: error: dereferencing pointer to incomplete type ‘SSL {aka const struct ssl_st}’
                 if (ssl->s3) {
                        ^~
core/ssl.c: In function ‘uwsgi_ssl_session_new_cb’:
core/ssl.c:64:69: error: dereferencing pointer to incomplete type ‘SSL_SESSION {aka struct ssl_session_st}’
         if (uwsgi_cache_set2(uwsgi.ssl_sessions_cache, (char *) sess->session_id, sess->session_id_length, session_blob, len, uwsgi.ssl_sessions_timeout, 0)) {
                                                                     ^~

[unbit]

@xrmx is see no other solution than removing the ssl cache sync feature (well i do not think anyone is using it...)

[xrmx]

@unbit i've updated the branch above, any chance you can give it a run? It compiles fine on my machine with openssl 1.1.0 but I haven't tested it.

My only concern is that in both core/ssl.c and http/spdy3.c we have to ifdef this kind of code. Is it a security issue? Like now we can downgrade to a weaker crypto?

+#if OPENSSL_VERSION_NUMBER < 0x10100000L
                 if (ssl->s3) {
                         ssl->s3->flags |= SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS;
                 }
+#endif

[unbit]

Looks good to me. It is sad we need to disable a feature, but i suppose no-one will cry for this :)

[xrmx]

@jonassmedegaard You can cherry-pick 2b3fb73 for building against openssl 1.1.0

[jonassmedegaard]

Thanks!

[melvyn-sopacua]

This still gives linker errors (after fixes done in 5537b69) on FreeBSD. I assume tests done here use an openssl version built with OPENSSL_API_COMPAT, as the linker errors all reference functions guarded by that flag:

core/subscription.o: In function `uwsgi_remove_subscribe_node':
core/subscription.c:(.text+0x7ad): undefined reference to `EVP_MD_CTX_destroy'
core/subscription.c:(.text+0x7d9): undefined reference to `EVP_MD_CTX_destroy'
core/subscription.o: In function `subscription_new_sign_ctx':
core/subscription.c:(.text+0x15bb): undefined reference to `EVP_MD_CTX_create'
core/subscription.c:(.text+0x15f4): undefined reference to `EVP_MD_CTX_destroy'
core/ssl.o: In function `uwsgi_ssl_init':
core/ssl.c:(.text+0xc): undefined reference to `SSL_library_init'
core/ssl.c:(.text+0x11): undefined reference to `SSL_load_error_strings'
core/ssl.c:(.text+0x16): undefined reference to `OPENSSL_add_all_algorithms_noconf'
core/ssl.o: In function `uwsgi_ssl_new_server_context':
core/ssl.c:(.text+0x473): undefined reference to `SSLv23_server_method'
core/ssl.o: In function `uwsgi_rsa_sign':
core/ssl.c:(.text+0xd4e): undefined reference to `SSL_library_init'
core/ssl.c:(.text+0xd53): undefined reference to `SSL_load_error_strings'
core/ssl.c:(.text+0xd58): undefined reference to `OPENSSL_add_all_algorithms_noconf'
core/ssl.c:(.text+0xde5): undefined reference to `EVP_MD_CTX_create'
core/ssl.c:(.text+0xf2d): undefined reference to `EVP_MD_CTX_destroy'
core/ssl.o: In function `uwsgi_opt_sni':
core/ssl.c:(.text+0x1243): undefined reference to `SSL_library_init'
core/ssl.c:(.text+0x1248): undefined reference to `SSL_load_error_strings'
core/ssl.c:(.text+0x124d): undefined reference to `OPENSSL_add_all_algorithms_noconf'
core/ssl.o: In function `uwsgi_ssl_add_sni_item':
core/ssl.c:(.text+0x130e): undefined reference to `SSL_library_init'
core/ssl.c:(.text+0x1313): undefined reference to `SSL_load_error_strings'
core/ssl.c:(.text+0x1318): undefined reference to `OPENSSL_add_all_algorithms_noconf'
core/legion.o: In function `uwsgi_legion_register':
core/legion.c:(.text+0x2a23): undefined reference to `EVP_CIPHER_CTX_init'
core/legion.c:(.text+0x2b30): undefined reference to `EVP_CIPHER_CTX_init'
plugins/http/https.o: In function `uwsgi_opt_https2':
plugins/http/https.c:(.text+0x2bc): undefined reference to `SSL_CTX_get_ex_new_index'
cc: error: linker command failed with exit code 1 (use -v to see invocation)

Defining OPENSSL_API_COMPAT (CFLAGS+=-DOPENSSL_API_COMPAT=0x10000000) during uWSGI build doesn't help. It isn't a lot to fix and the best approach (also with respect to commit 2b3fb73) is probably to follow the OpenSSL wiki and implement the new functions.

[melvyn-sopacua]

The above is because the www/uwsgi FreeBSD port doesn't correctly link with OpenSSL if installed from ports. You get a mix of 1.0 headers from base system in /usr/include and link OpenSSL from ports in /usr/local/lib.
Patch to the port's Makefile in order to use 2b3fb73 would be:

diff --git a/www/uwsgi/Makefile b/www/uwsgi/Makefile
index 73c783e..a0eeddd 100644
--- a/www/uwsgi/Makefile
+++ b/www/uwsgi/Makefile
@@ -12,7 +12,7 @@ COMMENT= Developer-friendly WSGI server which uses uwsgi proto
 LICENSE=   GPLv2
 LICENSE_FILE= ${WRKSRC}/LICENSE

-USES=      python
+USES=      python ssl
 USE_PYTHON=   distutils
 USE_RC_SUBR=  uwsgi

@@ -43,6 +43,8 @@ O_XML=      libxml2
 O_XML=     false
 .endif

+CFLAGS+=   -I${OPENSSLINC}
+LDFLAGS+=  ${OPENSSL_LDFLAGS}
 MAKE_ENV+= CPUCOUNT=${MAKE_JOBS_NUMBER} UWSGI_EMBED_PLUGINS=cgi

 PYSETUP=         uwsgiconfig.py

[xrmx]

@melvyn-sopacua nice, thanks for digging the issue. I have no clue on how to forward the issue to freebsd though.

[melvyn-sopacua]

@xrmx Already done. It wasn't until I put in forward compatible code, that I realized I was hitting that code, while I shouldn't be. Then the proverbial light bulb came on.

[jleclanche]

@xrmx @unbit Is there a release planned with these changes? Right now, pip install uwsgi on debian stretch fails.

Edit: Mixed up version numbers

[xrmx]

@jleclanche a 2.0.15 release is planned, personally i don't have much free time to spend on uwsgi lately

[unbit]

@jleclanche the #1490 is blocking the release, as soon as it is fixed i will upload the 2.0.15

[nooperpudd]

Very much look forward to 2.0.15 release.

[unbit]

It has been scheduled for 20170330: https://github.com/unbit/uwsgi-docs/blob/master/Changelog-2.0.15.rst

[numbsafari]

2.0.15 is up on pypi, so this can be closed, no?

[enchantner]

Guys, any news on fixing this one? I see @xrmx should have fixed this already, but I still can't build 2.0.18 with OpenSSL 1.1.1. What should I do?

[xrmx]

@enchantner double check you are not doing something silly and open a new issue with a proper error and environment info.