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. 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. 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 :-) Regards Estartu -- ------------------------------------------------- Gerhard Schmidt | E-Mail: schmidt at ze.tum.de TU-M?nchen | Jabber: estartu at ze.tum.de WWW & Online Services | Tel: 089/289-25270 | Fax: 089/289-25257 | PGP-Publickey auf Anfrage -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20150323/9cf62237/attachment.sig>
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>
On 24/03/2015 12:16 AM, 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. > > 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. > > 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 :-) > > Regards > Estartu > >I only use openssl from ports and have just completed a rebuild of 662 packages for server requirements and include: trousers, ldap client and server, and 71 other ports built without any issues on amd64 10.1Stable using clang. Not so successful on i386 but I don't believe its related to openssl. My 2c. Regards, Dewayne PS Of the ports I use, only ports-mgmt/pkg and sysutils/monit link against base openssl as they don't provide an option. :(