Compile error for ALPN functions in 5.0.0 (undeclared WOLFSSL_ALPN_CONTINUE_ON_MISMATCH)

[rockdaboot]

trafficstars

A FreeBSD user reports a compile error for GNU Wget2: https://gitlab.com/gnuwget/wget2/-/issues/571

ssl_wolfssl.c:877:49: error: use of undeclared identifier 'WOLFSSL_ALPN_CONTINUE_ON_MISMATCH'

as well as warnings about missing ALPN function declarations.

The code works for the previous versions (< 5.0.0) as in

#include <wolfssl/options.h>
#include <wolfssl/ssl.h>
...
wolfSSL_UseALPN(...)

[kareem-wolfssl]

Hi @rockdaboot ,

Using FreeBSD's wolfSSL config (found here), I see ALPN is not enabled, so HAVE_ALPN is not defined. However, ssl_wolfssl.c in wget2 is not guarding ALPN functions/identifiers with #ifdef HAVE_ALPN, so this leads to a compilation error rather than disabling ALPN. I would recommend either guarding ALPN functions with #ifdef HAVE_ALPN, or clarifying that wget2 requires wolfSSL's ALPN support to be enabled.

Thanks, Kareem

[AMDmi3]

alpn is disabled by default in wolfssl:

wolfssl-5.0.0% ./configure --help | grep alpn
  --enable-alpn           Enable ALPN (default: disabled)

that's most likely why it's also disabled in FreeBSD port. We can probably enable it in the port (does it have any drawbacks?), but it won't solve the problem with other distros which prefer to respect upstream defaults. I see the solutions as @kareem-wolfssl suggested, and additionally enabling it in wolfssl by default (again, depending on whether they are possible drawbacks).

[rockdaboot]

@kareem-wolfssl Thanks for your answer !

Wget2 currently only supports HTTP/2 via ALPN. So I assume HTTP/2 doesn't work any more without HAVE_ALPN. AFAIR, servers also announce HTTP/2 via HTTP headers - have to look into this. Until then, we could check for ALPN in configure.ac and disable HTTP/2 if not enabled.

[rockdaboot]

@AMDmi3 Can we close this issue ?

[AMDmi3]

@rockdaboot I've no idea. The issue was not resolved and no solution was proposed.

If it's going to be resolved on wget2 side by fixing the build with wolfssl with disabled alpn (even if it leads to disabling HTTP2 support), then this can probably be closed.

Otherwise it needs to be resolved on wolfssl side by enabling alpn by default. Are there reasons against it?

[kareem-wolfssl]

Hey @AMDmi3 ,

We don't enable this by default, as it is not required by everyone, and we aim to keep our default configuration as small as possible. Even if we did enable it by default, a user could disable it and try to build wget2, and run into this issue. The solution is to only compile/use ALPN if wolfSSL was built with support for it. Since your HTTP/2 feature depends on it, you will need to check if wolfSSL was built with ALPN when building wget2, and disable HTTP/2 if not.

Let me know if you have any further questions on this.

Thanks, Kareem

[rockdaboot]

Thanks @kareem-wolfssl ! IMO, this is definitely shouting for a run-time check. I am notthat deep into the API, maybe you can give me a hint how to do this ?

[kareem-wolfssl]

Sure, first make sure you are including wolfssl/options.h before any other wolfSSL headers. Then, wrap your wolfSSL ALPN/HTTP2 code in: #ifdef HAVE_ALPN ... #endif. You will probably want to provide an #else case which returns an error like "not compiled in".