Re: [squid-users] Compiling squid-3.3.5 with SSL on RedHat EL 6

From: Eliezer Croitoru <eliezer_at_ngtech.co.il>
Date: Wed, 22 May 2013 08:42:22 +0300

On 5/22/2013 8:20 AM, Amos Jeffries wrote:
> Things to be aware of:
>
> * feature-detection by ./configure can fail when there are more than one
> library version installed. The feature detecion may test the OS default
> library in /usr, then some unrelated library adds /usr/local or /opt or
> similar where files for a second library version gets used by the build.
> This is true for all libraries, not just OpenSSL.
> The fix here is to explicitly point --with-openssl= at the particular
> path for the desired library whenever there are more than one installed.
>
> * These feature-detection patches make allowance for most permutations
> of the known problems. But cannot handle the event where both our
> workaround and the official API are failing. If you can be certain you
> are hitting one of these cases we would like to know what OpenSSL
> version is doing it
>
> * the FIPS library versions which were also failing earlier with
> apparently the same build errors. I believe these FIPS builds are also
> fixed as a result of the featrue detection, but that is so far
> unconfirmed. I do know the FIPS libraries have significantly more chance
> of hitting the above case where our workarounds do not work.
>
> * There may be other OpenSSL API problems hidden in any given library
> which we are still unaware of and unfixed. 3.3.5 changes only decouple
> the existing version-based workarounds from the library version.
>
> In any event, the only real fix for these problems is to replace the
> broken library versions with update working ones.
Can it be that two exactly identical CentOS systems do the same
configure and make will result in a different result?
They only thing I can think of is a corrupted library that result in a
corrupted library on the OS and this is not a very nice thing to know.
To make sure our libs are identical we can use SHA1 or a more complex
calculation to verify his lib corruption reason.

Eliezer

>
> Amos
Received on Wed May 22 2013 - 05:42:47 MDT

This archive was generated by hypermail 2.2.0 : Wed May 22 2013 - 12:00:07 MDT