28 May
2009
28 May
'09
5:47 a.m.
On May 28, 2009 at 12:19, Juha Heinanen <jh(a)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