On May 28, 2009 at 12:19, Juha Heinanen jh@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