openssl

[Scott Haneda]

On Jul 9, 2009, at 1:07 AM, Bryan Blackburn wrote:

> On Wed, Jul 08, 2009 at 09:21:40PM -0700, Scott Haneda said:
> [...]
>>>
>>> http://trac.macports.org/wiki/FAQ#WillMacPortslinktosystemlibrariesratherthanitsown
>>>
>>> and the entry following that.
>>
>> Thanks.  One thing that is not clear, is you say "make sure things
>> link to".  How does one do that, the docs above do not explain that.
>> When I make a port file, especially in the case of p5's, it is pretty
>> simple.  I have never seen any way to specify any paths for linking
>> to any dependencies libs.
>
> By default though, port should be telling most software how to find  
> the
> right headers and libraries installed by MacPorts with various
> configure-time settings.  You should be able to see this if you run  
> port in
> debug, eg for p5-io-socket-ssl:
>
> DEBUG: Environment: CFLAGS='-pipe -O2 -arch i386' CPPFLAGS='-I/opt/ 
> local/include' CXXFLAGS='-pipe -O2 -arch i386'  
> MACOSX_DEPLOYMENT_TARGET='10.5' CPP='/usr/bin/cpp-4.0' CXX='/usr/bin/ 
> g++-4.0' F90FLAGS='-pipe -O2 -arch i386' LDFLAGS='-L/opt/local/lib - 
> arch i386' FCFLAGS='-pipe -O2 -arch i386' OBJC='/usr/bin/gcc-4.0'  
> INSTALL='/usr/bin/install -c' PERL_AUTOINSTALL='--skipdeps'  
> OBJCFLAGS='-pipe -O2 -arch i386' FFLAGS='-pipe -O2 -arch i386' CC='/ 
> usr/bin/gcc-4.0'
>
> Note the -I/opt/local/include and -L/opt/local/lib in there.

Ok, I always run on debug mode, I will look out for those thing.  When  
I am installing something like ASSP, it has 20 or so p5's to do, so  
there is a lot going by.  I will do them one at a time and look at each.

>> I updated openssl, `sudo port updgrade openssl`
>> 	$which openssl
>> 	/opt/local/bin/openssl
>> 	$/opt/local/bin/openssl version
>> 	OpenSSL 0.9.8k 25 Mar 2009
>>
>> 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?

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?

>> 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.

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.

I have little knowledge of how this all works, so it is hard for me to  
even make test cases.

>> I do not know if I just need to update openssl via ports, or if I
>> need to remove all related perl modules, and install them again, or
>> if I need to remove all of ASSP and install that again as well to get
>> the new bits.
>
> Worst case would call for rebuilding anything which links against  
> OpenSSL,
> but also make sure everything which wants it declares a dependency  
> on the
> port.  Otherwise, you end up with one port without the dependency  
> and then
> it may link against the system OpenSSL, then another port comes  
> along with
> that dependency and installs it then links against MacPorts' OpenSSL.
> If you try using those two together, you get a mess.

Perhaps I am in this mess.  I made many of these p5 port files, and  
most just amounted to finding an older p5, editing the name and  
version, dropping in a description, maintainer, and hash.  Maybe there  
was more research into those port files I needed to do. I looked at  
cpan for any dependencies, and add those as needed, but that is as far  
as I usually took it, other than running it, and if there were test  
cases, giving them a quick try. If it loaded, I considered it ok.

Last night, I ran sudo port -df uninstall all and removed everything.   
I then ran sudo port -d install assp.  It all went in, in one go, no  
errors, that was nice.

However, I am still not able to get ASSP to work in SSL mode.

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?

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.

This very well could be a bug in ASSP, and I am yet to find more than  
one person who has gotten this to work.  So far, I am having a hard  
time finding the person who wrote the SSL sub routines in ASSP, to  
even get to the point where it can be debugged.

>> Toss in postfix, which also uses openssl as well and I am not sure
>> what and where I need to look to update things.  Add to that, ASSP is
>> on a different machine than postfix, and I have two places I get to
>> answer these questions.  Ugh :)
>
> If they run on different servers, then precise OpenSSL versions should
> technically not matter, as long as the SSL/TLS protocols are properly
> followed.  Of course if there's a bug in the protocol handling of a  
> given
> version, then you have a problem.

Agreed.  I have been delivering email from several machines that can  
not deliver to ASSP, for years.  Millions of messages sent from php  
scripts that end up on some server somewhere.  I am confident that  
things are ok on those sending machines.  I am pretty sure the openssl  
versions on the MUA sending side, and the destination receiving side  
are ok.  So something is happening on the ASSP machine. (I am running  
the ASSP proxy on a separate machine)

>> So, by seeing "OpenSSL 0.9.8k 25 Mar 2009" in the version that I now
>> have installed, and seeing 0.9.8 returned by otool, does that mean
>> that when I ran port update openssl those files were updated?  Or,
>> does it mean that macports already happened to have the 0.98 versions
>> in place, and I just happened to get to use those?
>
> Hard to say, if you used 'port install openssl' then you didn't have  
> the
> port installed at all; if you used upgrade, then that's a bit odd as  
> the
> openssl port has never been at 0.9.7l, it went from 0.9.7g to 0.9.8  
> four
> years ago:
>
> <http://trac.macports.org/changeset/12976>

I used upgrade. I suspect this was PATH related, I may have been  
logged in as a user that did not have the .profile set up so it was  
polling the Apple supplied version.

>>>> There are no patche for IO::Socket::SSL, so it is just being
>>>> installed, nothing changed in it to point to a specific openssl.
>>>>
>>>> Further, p5-event none of the example in IO::Socket::SSL work for  
>>>> me.
>>>
>>> I'm not sure what you mean here.
>>
>> Me neither :) I had something on the clipboard I did not mean to
>> have.  I think I meant that, in the IO::Socket::SSL download, there
>> are a set of sample files, and running them, none of them work, and
>> all barf with errors.
>
> I tried a couple of them, the client and server are able to talk to  
> each
> other, though that isn't too surprising since they are using the same
> software; I also tried connecting to the server with the system  
> openssl
> command, and it was able to get the SSL cert just fine...

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.

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