On Mon, Oct 10, 2005 at 02:13:27AM +0200, Jeroen van Wolffelaar wrote: > > i'm still not quite happy with that last one, as gethostbyname isn't > > defined by posix/sus/iso, but it's being used elsewhere in the > > code base already, so oh well. > > As long as Debian supporst it across all architectures... But yeah, something > for upstream to generalize if possible.
yeah. i guess i tend to keep that in mind, as i'm also on the upstream development team :) but since they were using gethostname already in the code... whatever. > Anyway, it doesn't work yet over here completely. I get a segmentation fault > in the call to SSL_CTX_free(ctx). sounds like some error checking isn't catching the ssl connection not being properly established. > Feel free to use mail.wolffelaar.nl as test SMTP server as much as you like, > by the way. It's default sarge exim4 with TLS enabled, otherwise nothing > really special that should be relevant for this check. cool, thanks. i suspect that it actually is relevant though, as i see something later on about gnutls, and istr reading another bug report about openssl extensions causing problems in non-openssl environments. don't know it well enough to know whether or not that could be the case here though, i'll look into it. > #0 0x40072f77 in SSL_SESSION_hash () from /usr/lib/i686/cmov/libssl.so.0.9.8 > #1 0x401272c7 in lh_delete () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 > #2 0x400773d8 in SSL_CTX_get_timeout () from > /usr/lib/i686/cmov/libssl.so.0.9.8 > #3 0x40126f34 in lh_doall_arg () from /usr/lib/i686/cmov/libcrypto.so.0.9.8 > #4 0x4007750e in SSL_CTX_flush_sessions () from > /usr/lib/i686/cmov/libssl.so.0.9.8 > #5 0x400730cc in SSL_CTX_free () from /usr/lib/i686/cmov/libssl.so.0.9.8 > #6 0x08049777 in my_close () at check_smtp.c:759 > #7 0x08049813 in connect_STARTTLS () at check_smtp.c:655 > #8 0x0804a7ae in main (argc=3, argv=0xbffffaf4) at check_smtp.c:236 probably freeing something that was never successfully allocated. > I also see no code doing a QUIT over the TLS'd connection, or for that matter, > anything. I don't think that'd really be needed though, it's definitely not in > the scope of the original check_smtp... Though I guess it's actually going to > cause a log entry (exim tends to log "connection closed unexpectedly" if there > is no QUIT). Currently my logs for the SEGV'ing check_smtp say: it will send a QUIT if told to do starttls and the server doesn't support it, or at the end of the SMTP conversation (independant of whether the connection is SSL-enabled). iirc SMTP requires the client send a quit before closing the connection. the one place it doesn't do a QUIT is if there's an error with connect_STARTTLS, but that's because there's been some application error and the connection/encryption is in a rather undefined state. > 2005-10-10 02:11:13 TLS error on connection from 22pc220.sshunet.nl > (bla.wolffelaar.nl) [145.97.220.22] (gnutls_handshake): Could not negotiate a > supported cipher suite. probably an openssl/gnutls thing. i don't know a lot about openssl, but i'm guessing some SSL_get/set_cipher_list might resolve that. > > + localhostname = malloc (HOST_MAX_BYTES); > > + gethostname(localhostname, HOST_MAX_BYTES); > > Hm, if gethostname fails, you end up with a bogus localhostname, but you don't > detect that and continue anyway. Fwiw, this was already present in the old > code too. Now fortunately nobody but root can set the hostname... Or it'd be a > security hole. i'll put some more error checking in there. out of curiosity though, how can calling gethostname set the hostname? > check_smtp.c:134: warning: unused variable 'ehlo_resp' > check_smtp.c:131: warning: unused variable 'amt_read' my bad, was from earlier hacking attempts sean --
signature.asc
Description: Digital signature