cURL / Mailing Lists / curl-library / Single Mail

curl-library

Need advice on handling CyaSSL/wolfSSL's build configurations

From: Ray Satiro via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 16 Apr 2015 01:05:18 -0400

Recently I made some changes to lib/vtls/cyassl.c to include the CyaSSL
build options [1] and support SNI [2]. The latter change is dependent on
the former.

CyaSSL's includes do not themselves include its build options (file
cyassl/options.h) but the defines in that file are needed by the other
includes to determine which optional function declarations to expose,
and it's possible some structures may be affected as well. There is an
exception to not including the build options for some embedded platforms
which have kind of a de facto options.h (cyassl/ctaocrypt/settings.h)
that is included by the other includes.

Because of the above I determined that the options.h needs to come
before any CyaSSL include. As you can see in the commit I put it before
all other cyassl, however smoke testing has shown urldata.h includes a
CyaSSL include so really I would need to place the options.h before
everything. That could be a problem --or rather could be more of a
problem-- because it turns out the options.h redefines some important
symbols DEBUG or NDEBUG, which I reported as a bug and has been (mostly)
fixed just recently [4]. It's an issue for me on Visual Studio, and
maybe other build systems as well.

As you can see from the first draft of the kludge [5] to remedy, I have
a workaround for any CyaSSL/wolfSSL version in which the issue is not
fixed (currently all) which is to save DEBUG and NDEBUG before CyaSSL
includes and restore afterwards. It only works assuming DEBUG and NDEBUG
are just the default 1 if they are defined (big assumption) and it
doesn't handle other symbols like _POSIX_THREADS, for example.

I'm left with a dilemma. A second draft to account for all of above is
just going to be more kludgy. And as you can see in [4] the
_POSIX_THREADS part is still an open issue. As I mention in [4] I'm
thinking about doing an ac_check_funcs in the curl configure.ac for the
SNI function, and then define HAVE_SNI based on that. I would also have
to do something to test for NO_FILESYSTEM. There used to be functions
exposed only when NO_FILESYSTEM but I recall they changed that recently
so they are always exposed.

Another idea is maybe only include options.h if it's from a version
where they fix it. So assuming it's fixed in the next version, something
like:
#if defined(HAVE_CYASSL_OPTIONS_H) && (LIBCYASSL_VERSION_HEX > 0x03004008)
#include <cyassl/options.h>
#endif
People with older versions of the library would get the same old
behavior, but no HAVE_SNI and no NO_FILESYSTEM (exception is embedded
versions).

Any suggestions?

[1]: https://github.com/bagder/curl/commit/72bea7c
[2]: https://github.com/bagder/curl/commit/9430dd5
[3]: https://github.com/bagder/curl/blob/72bea7cc/lib/vtls/cyassl.c#L37
[4]: https://github.com/wolfSSL/wolfssl/issues/65
[5]: https://github.com/jay/curl/commit/a6621b3

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-04-16