openssl

[Bryan Blackburn]

On Thu, Jul 09, 2009 at 11:25:26AM -0700, Scott Haneda said:
> On Jul 9, 2009, at 1:07 AM, Bryan Blackburn wrote:
> >On Wed, Jul 08, 2009 at 09:21:40PM -0700, Scott Haneda said:
[...]
> >>Does that mean, that p5-net-ssleay will now use the updated version?
> >>Maybe I do not get this, and openssl updates just the binary, and has
> >>nothing to do with the libs.
> >
> >Upgrading the port upgrades all bits for it, any binaries, libs,
> >headers,
> >etc.  So if 'openssl version' says 0.9.8k, then the headers and
> >libraries
> >should be that version as well.
> 
> port upgrade openssl took all of 5 seconds, if that.  I would have
> expected it to take longer, if it had to rebuilt modules that
> depended on it.  Or are these libs and headers just files that get
> pointed to, and not built into the binary.  The binary just holds
> paths to the libs and headers?

If upgrade is really quick like that, sounds like it actually had nothing to
do (eg, you're already current for the given port).  'port upgrade' will
also upgrade ports on which openssl depends, but not ports which themselves
depend on openssl.

The way the openssl binary works is that it is linked to the libssl and
libcrypto libraries (as you can see if you use 'otool -L
/opt/local/bin/openssl'), and these paths are encoded in the binary.

> 
> So, If I were to take a binary that was made on an intel machine, and
> take it to another identical intel machine, but did not bring along
> the libs and headers, it would not work until I did so?

Because of those paths being encoded into the binary, copying only the
openssl file would not work since you'd also need the libs.

> 
> >>What I do know, is ASSP needs p5-net-ssleay, there is a suspicion
> >>that the openssl version I am working against is too old, or too
> >>buggy, so I need to try to solve that.
> >
> >Hard to say without knowing how things aren't working; I know some
> >software
> >doesn't like when you compile using one version of headers then
> >link against
> >a different version of libraries.
> 
> ASSP is a email proxy, it supports SSL and TLS mostly by using p5's
> to make it all happen.  The setup is Internet -> ASSP -> MTA
> 
> If I made a SSL or TLS enabled connection directly to the MTA on port
> 25, SSL and/or TLS will work fine.
> 
> If I make a connection to the ASSP proxy, it works some of the time.
> I send a email in the command line:
> `mail user at remote-mta-machine`
> This will always work
> 
> `mail user at assp-proxy` this simply hits port 25, which is set to
> proxy to the far end MTA.  It fails the SSL parts entirely.  Some
> hosts that I send the `mail` command from work, others do not. I
> subscribed to a few mailing lists, some get through, some do not.

Some addresses working and others not, that doesn't sound like an initial
connection issue (which would implicate SSL/TLS) but something after that.
By 'fails the SSL parts entirely' what exactly do you mean, does it fail to
finish the initial TCP handshake, fail to verify the cert, something else?

> 
> I can use openssl as a client, and connect to the remote far end MTA
> just fine, connecting to ASSP, and I get the connection, but that is
> as far as I get.

If you can see the cert (eg, by using --showcerts with s_client) then that
sounds like SSL/TLS is working fine.

[...]
> 
> I know what p5's ASSP installs, and can easily tell what dependencies
> I need to track down to look at.  However, those depend on perl,
> which was installed, and curses was installed;  a lot of other things
> too.  Can I be reasonably confident, if any of those use openssl libs
> and headers, I need not run otool on them, and do any checking?

The big problem is that for any new ports, checking linkage is a good thing,
especially for bits that get loaded into larger programs (like perl
modules).  If you aren't careful you can end up with one part linking to the
system library and another part to the MacPorts equivalent.  This can then
lead to version mismatches and software crashing.

> 
> Can you suggest any automated why to run otool against all the p5's
> and anything else you can think of, so I can find out if this is the
> area of my problems.

I'm not aware of anything automated, I simply run 'otool -L' against any
executables in bin/, .dylib files, .so files, and .bundle files.  For a new
port I usually just use 'port destroot' to get it to build but not install,
then check the contents of the destroot for these files and check them
there.  For p5-net-ssleay, for example, it has one bundle file (which is its
linkage to OpenSSL, through the C interface) in

/opt/local/lib/perl5/vendor_perl/5.8.9/darwin*/auto/Net/SSLeay/SSLeay.bundle

so checking that will show against which OpenSSL it is linked (I use darwin*
in the path there because it may be different depending on how perl5.8 is
installed variant-wise).

[...]
> 
> Can you show me how you tried them, I was not able to get them to
> work, but all I did was `perl filename` which probably was not a
> valid way to test.  I really do not know perl, or SSL vocabulary well
> enough to properly test these out.

After it built (I have port's autoclean off so the build dir was still
available), I simply move into the top dir for p5-io-socket-ssl (the one
with the example directory among others).  From here, I ran

$ /opt/local/bin/perl5.8 example/ssl_server.pl

in one terminal and the ssl_client.pl in another, and watched those talk
fine.  Leaving the ssl_server process up, I then used

$ openssl s_client -connect localhost:9000 -showcerts -debug

to connect to the server and verify it was able to get the cert, which it
did.

Bryan


> 
> Thanks Bryan.
> -- 
> Scott * If you contact me off list replace talklists@ with scott@ *
>