Problems with openssl 1.0.2 update

[Guido Falsi]

On 03/23/15 14:16, Gerhard Schmidt wrote:
> On 23.03.2015 13:40, Guido Falsi wrote:
>> On 03/23/15 11:33, Gerhard Schmidt wrote:
>>> Hi,
>>>
>>> we experiencing a problem after upgrading  the openssl port to openssl
>>> 1.0.2.
>>>
>>> /usr/bin/vi started to crash after some seconds with segfault.
>>> /rescue/vi works just fine. Deleting the openssl 1.0.2 package
>>> everything works just fine again. Installing the old openssl 1.0.1_18
>>> package it still works just fine.
>>>
>>> it seams that besides vi the bash also has this problem. Anybody
>>> experiencing the same or is this something specific to my system.
>>>
>>> I'm running FreeBSD 10.1 updated tonight.
>>
>> I am seeing runtime problems with asterisk13 (which I maintain), caused
>> by the OpenSSL update fallout.
>>
>> In this case, after some analysis, I concluded the problem is the
>> libsrtp port requiring OpenSSL from ports(for a reason), causing
>> asterisk to link to that too, which would be correct.
>>
>> Asterisk also uses the security/trousers port, which links to system
>> OpenSSL. This ensues a conflict which now results in asterisk
>> segfaulting and stopping to work.
>>
>> I'm investigating what can be done about this. As a local solution I can
>> force the trousers port to link against OpenSSL from ports, but this
>> will not fix the general problem. As a port maintaner I ony see
>> modifying the trousers port to depend on ports OpenSSL as a solution, is
>> this acceptable?
>>
> Most Ports link against the port openssl if its installed and agains the
> system openssl if not. That should be the prefered way to handle problem.
> 

Sorry, I forgot to mention this is happening when building in poudriere.

in poudriere trousers will be unconditionally linked against base
OpenSSL, since nothing will pull in ports openssl when building trousers
(and others I'm discovering).

When poudriere builds asterisk, it will pull in a dependency bringing
OpenSSL from ports and asterisk will link against that, but the binary
package for trousers knows nothing and will still depend on base openssl.

So, the packages will build fine in most cases, but will fail in
unexpected ways at runtime.

I can fix this in my system by putting WITH_OPENSSL_PORT=yes in
make.conf and link everything against that, but this isn't a viable
solution for fixing it on the cluster.

> I don't know if an incompatibility between system an port openssl is a
> problem. I've removed the portbuild openssl from this server completely.

Mostly depends on the port. My fear is there could be other similar
problems lurking in binary packages.

> 
> As far as i can see the problem is with openldap-client build agains the
> ports openssl and used by nss_ldap or pam_ldap modul. I will do some
> testing when my test host is ready. Testing on an Production server is
> not that good :-)

This is a similar problem. but also involves base, so it's even harder
to solve.

-- 
Guido Falsi <madpilot at FreeBSD.org>