[sr-dev] tls related compiler warnings

[Andrei Pelinescu-Onciul]

On May 28, 2009 at 12:19, Juha Heinanen <jh at tutpro.com> wrote:
> while compiling modules/tls, i get a some warnings:
> 
> tls_config.c: In function ??parse_ipv6??:
> tls_config.c:67: warning: implicit declaration of function ??str2ip6??
> tls_config.c:67: warning: assignment makes pointer from integer without
> a cast

This is strange, I do not get it. str2ip6 is defined in resolve.h, which
is included by tls_config.c, so you shouldn't get it either...
> 
> and
> 
> tls_init.c:71:10: warning: #warning "openssl zlib compression bug workaround enabled"

There are a lot of bug workarrounds for specific openssl versions. See
the modules's README for more details.

> tls_init.c:89:3: warning: #warning "openssl < 1.0: no TLS extensions or server name support"
> 
> and
> 
> tls_server.c: In function ??tls_h_nonblocking_write??:
> tls_server.c:811: warning: label ??again?? defined but not used

That's a function which made it in by mistake during the merge. I wanted
to use for tls async support, but that's not ready it. It can safely be
commented out completely for now.

> 
> how to get rid of them (the last looks easy)?  do i have wrong version
> of openssl dev package?

It depends, if you want to use TLS extensions (for now this means
getting the TLS server name extension from the script via the
@tls.serverName select or the &tls_peer_serve_name pvar) then you need
at least the 1.0 version of openssl. If you don't you can stick with the
older version.

> 
> ii  libssl-dev                           0.9.8g-15+lenny1           SSL development libraries, header files and 
> 
> by the way, why is tls implementation based on openssl instead of
> gnutls?

Because at the time the first tls implementation started, gnutls was
very new.
While it's true that openssl has a lot of bugs (especially a lot of
unchekced mallocs() which are present even in modern versions and some
multiprocess problems which seem to be solved in the latest versions),
at least we know them and we have a lot of workarounds for various
openssl versions. Since so far nobody tried a gnutls implementation we
do not know if it stands better or if we'll need again a ton of
 new workarounds.

The problem with a new implementation is that it will need a lot of
testing and so far it looks like extremely few people are using
ser/k/openser with tls in a demanding environment (the best proof for
this is that the k/openser implementation had some critical bugs in it
that would have cause crashes under heavy use).


Andrei