I think the easiest way to find out with which version of openssl was
link squid is to use ldd
# ldd /usr/sbin/squid | grep ssl
libssl.so.10 => /usr/lib64/libssl.so.10 (0x00007ff8b13d6000)
On Wed, May 22, 2013 at 8:42 AM, Eliezer Croitoru <eliezer@xxxxxxxxxxxx> wrote:
> 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
>
>
