[Date Prev] [Date Index] [Date Next] [Thread Prev] [Thread Index] [Thread Next]

beta OpenSSL patches available

Bryan Stansell bryan@conserver.com
Thu, 10 Oct 2002 14:04:34 -0700 (PDT)


The second round of patches for OpenSSL support within conserver is
available.  There are still some changes that will be necessary before
they're all official, but it's a pretty strong set of code (at least on
my boxes).  The support for certificates may or may not actually work
(I tried quickly one night with self-signed certificates and the
OpenSSL library kept complaining about them - I'm pretty sure I created
them wrong), and the encryption only current happens when you connect
to a console (not when you're doing a 'console -i', for example).  But,
without the certificates and the 100% encryption, I've been very
successful in hiding the client/server traffic from tcpdump.  ;-)

You can find them at ftp://ftp.conserver.com/conserver/openssl-patches/
or http://www.conserver.com/openssl-patches/ in the file
7.2.3-to-7.2.4-beta1.patch.

I'm hoping that either one or two more rounds of changes will result in
the final 7.2.4.  I'm not expecting to get everything related to
OpenSSL fully functional and stabilized, but it should be close.  If
you're able to spend a little time just doing a compile test on a
system (especially HP-UX, AIX, or other "troublemakers"), I'd love to
know if you run into issues (like the whole shadow password build bug
in 7.2.3).

And now, the complete list of changes...

version 7.2.4 ():
        - added --with-openssl for client/server encryption
        - added -E option to client and server to allow for non-encrypted
          connections (encryption is the default if compiled in)
        - added -c option so credentials (certificate and key) can be
          exchanged between client and server
        - expanded -V output to show what optional bits actually got
          compiled into the code (libwrap, regex, etc)
        - compilation errors on non-shadow file systems without using
          --with-pam - reported by Jesper Frank Nemholt <jfn@dassic.com>
        - client now prefers $LOGNAME, then $USER, then the current uid
          for it's -l default - suggested by Dave Stuit <djs@tellme.com>
        - putting back socklen_t usage - it's the right thing to do,
          so tell me where it breaks things

Bryan