[TriLUG] SSL Issues

[Benjamin Reed]

On Tuesday, September 17, 2002, at 10:26 PM, Robert Porter wrote:

> I have paid for the up2date subscription and use it, but that caused 
> other
> issues, especially with OpenSSL.  Redhat "backpatched" versions of the 
> SSL
> libraries to fix the recent buffer overruns, this means that the 
> versions
> reported don't match anymore.  I did do a binary install of MySql via 
> RPM's
> from the ISO images with no problem.  However I am finding that some 
> packages
> installed via RPM and some installed via source tar balls seem to cause
> problems, the least of which is the RPM's tend to conform to RedHat's 
> idea of
> file locations and the source tar balls adhere to more "standard" 
> locations
> if there is such a thing :'>  If you ask me RPM's are creating a Linux
> version of Microsoft DLL Hell.  But that's most likely my ignorance of 
> RPM
> technology speaking.

You only get DLL hell if you just install RPMs willy-nilly from 
anywhere.  Anything I download that isn't direct from my distro, I 
rebuild from source RPM, and then everything is fine.  (well, there's 
always exceptions, but it's much safer than overwriting system libs)

> My real issue is how to get rid of the RedHat RPM based version of 
> OpenSSL and
> replace it with a configure/make/make install version without 
> destroying my
> system.  Any help would be most appreciated.

Your real issue is that you're asking the wrong question.  You're 
basically saying, "How do I break this window without putting a hole in 
it?"  =)

What you really need to do is rephrase what you want.

OpenSSL breaks binary compatibility pretty regularly, so you *can't* be 
certain, without making sure you have your new libraries *and* leave 
redhat's libraries alone.

The best way to handle it is to just not do it.  In your initial 
reasoning, you said you needed a rebuilt apache for mod_jk, but mod_jk 
works just fine as a DSO module, so I'm not sure why the instructions 
you found required you to build things specially.  Even if you *have* 
to build it in, the only safe way to do it is to leave redhat's stuff 
alone, and then put your build in a sandbox, if you don't want to break 
all of the other things that depend on RedHat's OpenSSL.  So your 
*real* goal is to have a custom-built apache in a sandbox, not to 
replace important system libraries.

(disclaimer, this isn't *everything* step-by-step, but should give you 
an idea of how to handle it)

So what you'll want to do is make, say, an /opt/custom-apache directory 
(or /usr/local/custom-apache, or whatever, just something that's 
guaranteed not to be in "normal" system paths).

Then set up your environment to look there:

export PATH="/opt/custom-apache/bin:$PATH"
export LD_LIBRARY_PATH="/opt/custom-apache/lib:$LD_LIBRARY_PATH"

...and then build openssl with --prefix=/opt/custom-apache
...and then build apache with --prefix=/opt/custom-apache
...and build everything else that you want in your "apache sandbox" in 
there

Then you only need to make a script that sets up LD_LIBRARY_PATH and 
runs your custom httpd, and it will be the *only* thing that sees your 
custom libraries, rather than overwriting the defaults that the rest of 
the system uses.