WOLFSSL build is broken

[jrch2k20]

Just reporting WOLFSSL is broken on 0.5.0 as well.

LOG:

cc -march=native -O2 -pipe -fno-plt -ftree-vectorize -DLIBUS_USE_WOLFSSL -I/usr/local/include -std=c11 -Isrc -flto -O3 -c src/.c src/eventing/.c src/crypto/*.c
In file included from /usr/include/wolfssl/ssl.h:33,
from src/crypto/wolfssl.c:26:
/usr/include/wolfssl/wolfcrypt/settings.h:2060:14: warning: #warning "For timing resistance / side-channel attack prevention consider using harden options" [-Wcpp]
2060 | #warning "For timing resistance / side-channel attack prevention consider using harden options"
| ^~~~~~~
src/crypto/wolfssl.c: In function ‘ssl_on_end’:
src/crypto/wolfssl.c:116:12: warning: implicit declaration of function ‘us_internal_ssl_socket_close’; did you mean ‘us_internal_ssl_socket_write’? [-Wimplicit-function-declaration]
116 | return us_internal_ssl_socket_close(s);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
| us_internal_ssl_socket_write
src/crypto/wolfssl.c:116:12: warning: returning ‘int’ from a function with return type ‘struct us_internal_ssl_socket_t *’ makes pointer from integer without a cast [-Wint-conversion]
116 | return us_internal_ssl_socket_close(s);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/crypto/wolfssl.c: In function ‘ssl_on_data’:
src/crypto/wolfssl.c:142:20: warning: returning ‘int’ from a function with return type ‘struct us_internal_ssl_socket_t *’ makes pointer from integer without a cast [-Wint-conversion]
142 | return us_internal_ssl_socket_close(s);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/crypto/wolfssl.c:177:24: warning: returning ‘int’ from a function with return type ‘struct us_internal_ssl_socket_t *’ makes pointer from integer without a cast [-Wint-conversion]
177 | return us_internal_ssl_socket_close(s);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/crypto/wolfssl.c:183:28: warning: returning ‘int’ from a function with return type ‘struct us_internal_ssl_socket_t *’ makes pointer from integer without a cast [-Wint-conversion]
183 | return us_internal_ssl_socket_close(s);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/crypto/wolfssl.c:238:11: warning: assignment to ‘struct us_internal_ssl_socket_t *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion]
238 | s = us_internal_ssl_socket_close(s);
| ^
src/crypto/wolfssl.c: At top level:
src/crypto/wolfssl.c:435:6: error: conflicting types for ‘us_internal_ssl_socket_context_on_close’
435 | void us_internal_ssl_socket_context_on_close(struct us_internal_ssl_socket_context_t *context, struct us_internal_ssl_socket_t *(*on_close)(struct us_internal_ssl_socket_t *s)) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from src/crypto/wolfssl.c:21:
src/internal/internal.h:137:6: note: previous declaration of ‘us_internal_ssl_socket_context_on_close’ was here
137 | void us_internal_ssl_socket_context_on_close(struct us_internal_ssl_socket_context_t *context,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/crypto/wolfssl.c: In function ‘us_internal_ssl_socket_context_on_close’:
src/crypto/wolfssl.c:436:75: warning: passing argument 3 of ‘us_socket_context_on_close’ from incompatible pointer type [-Wincompatible-pointer-types]
436 | context_on_close(0, (struct us_socket_context_t *) context, (struct us_socket_t ()(struct us_socket_t )) ssl_on_close);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| struct us_socket_t * ()(struct us_socket_t *)

In file included from src/crypto/wolfssl.c:20:
src/libusockets.h:104:27: note: expected ‘struct us_socket_t * (*)(struct us_socket_t *, int, void )’ but argument is of type ‘struct us_socket_t * ()(struct us_socket_t *)’
104 | struct us_socket_t *(*on_close)(struct us_socket_t *s, int code, void *reason));
| ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/crypto/wolfssl.c: At top level:
src/crypto/wolfssl.c:560:34: error: conflicting types for ‘us_internal_ssl_socket_close’
560 | struct us_internal_ssl_socket_t *us_internal_ssl_socket_close(struct us_internal_ssl_socket_t *s) {
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/crypto/wolfssl.c:116:12: note: previous implicit declaration of ‘us_internal_ssl_socket_close’ was here
116 | return us_internal_ssl_socket_close(s);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/crypto/wolfssl.c: In function ‘us_internal_ssl_socket_close’:
src/crypto/wolfssl.c:561:48: error: too few arguments to function ‘us_socket_close’
561 | return (struct us_internal_ssl_socket_t *) us_socket_close(0, (struct us_socket_t *) s);
| ^~~~~~~~~~~~~~~
In file included from src/crypto/wolfssl.c:20:
src/libusockets.h:227:34: note: declared here
227 | WIN32_EXPORT struct us_socket_t *us_socket_close(int ssl, struct us_socket_t *s, int code, void *reason);
| ^~~~~~~~~~~~~~~
make: *** [Makefile:41: default] Error 1
==> ERROR: A failure occurred in build().
Aborting...

Tyvm for you awesome work

[ghost]

Yep WolfSSL is lagging behind a little bit. Will have to update it at some point.

[jrch2k20]

tyvm for your time, 0.4 still works fine for me, i'll be checking then to test once its updated :)

[mattfbacon]

Still broken. I would really like to use WolfSSL as opposed to OpenSSL but as of now it appears I will have to use OpenSSL.

[ghost]

WolfSSL support is (still) broken because a) nobody has expressed interest in fixing it (yet) and b) BoringSSL is way faster than OpenSSL, which in turn in way faster than WolfSSL.

So BoringSSL is where focus is being put, since it is, by far, outperforming every other SSL implementation I've tested. BoringSSL has the same interfaces as OpenSSL, so the same impl. works both ways.

[mattfbacon]

OpenSSL is way faster than WolfSSL? I thought it was the other way around.

Anyway, I find the recommendation of BoringSSL a bit strange. From Google's site:

Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is. We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.

Based on this I feel like WolfSSL is still the best option for a generic project. But thanks anyway for the insight into why WolfSSL support is not being actively maintained.

I would be willing to help but unfortunately I have zero knowledge of SSL or anything in that field.

[ghost]

WolfSSL is intended for embedded use. They have smaller memory footprint per connection than OpenSSL but are slower (for the same reasons). BoringSSL is what Google use in all their products and what is required for anything QUIC (which we are focusing on). So BoringSSL is definitely priority 1 here

[mattfbacon]

They have smaller memory footprint per connection than OpenSSL but are slower

Alright, I will take your word for it.

Thanks for the insight. I will just use OpenSSL.

[xanderdunn]

Also experiencing the broken wolfssl build.

@alexhultman thanks for the above performance guidelines. Are there any benchmarks you could link to, or specific situations where you found BoringSSL > OpenSSL > WolfSSL? This from 2017 seems to show that OpenSSL and BoringSSL have equivalent performance. This from 2018 seems to show WolfSSL is considerably faster than OpenSSL for TLS 1.3 on x86_64, albeit from a biased source.

[glingy]

I just got it working with the latest wolfssl-5.3.0 (libwolfssl.so.32.0.0). I haven't fully tested it yet, but it appears wolfssl has openssl compatibility headers, so using the openssl.c file and changing the includes at the top of the file to:

#include <wolfssl/options.h>
#include <wolfssl/openssl/ssl.h>
#include <wolfssl/openssl/bio.h>
#include <wolfssl/openssl/err.h>
#include <wolfssl/openssl/dh.h>

instead of openssl directly appears to be working. We might be able to simplify wolfssl support by just switching the includes based on wolfssl / openssl.