Date: Sun, 14 Oct 2018 05:36:28 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Daniel Eischen <deischen@freebsd.org> Cc: Cy Schubert <Cy.Schubert@cschubert.com>, Don Lewis <truckman@FreeBSD.org>, FreeBSD current <freebsd-current@FreeBSD.org>, re@FreeBSD.org Subject: Re: OpenSSL 1.1.1 libssl.so version number Message-ID: <201810141236.w9ECaSHd007740@slippy.cwsent.com> In-Reply-To: Message from Daniel Eischen <deischen@freebsd.org> of "Sat, 13 Oct 2018 14:02:37 -0400." <0F7EB379-8C52-478A-AA5A-AC4257E5B70A@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <0F7EB379-8C52-478A-AA5A-AC4257E5B70A@freebsd.org>, Daniel
Eischen w
rites:
>
>
> > On Oct 12, 2018, at 10:58 PM, Cy Schubert <Cy.Schubert@cschubert.com> wrote
> :
> >
> > In message <tkrat.3c3bfd84a6c58d9a@FreeBSD.org>, Don Lewis writes:
> >> Prior to the OpenSSL 1.1.1 import, the base OpenSSL library was
> >> /usr/lib/libssl.so.8. The security/openssl port (1.0.2p) installed
> >> ${LOCALBASE}/lib/ilbssl.so.9 and the security/openssl-devel port
> >> (1.1.0i) installed ${LOCALBASE}/lib/libssl.so.11. After the import, the
> >> base OpenSSL library is /usr/lib/libssl.so.9. Now if you build ports
> >> with DEFAULT_VERSIONS+=ssl=openssl, the library that actually gets used
> >> is ambiguous because there are now two different versions of libssl.so
> >> (1.0.2p and 1.1.1) with the same shared library version number.
> >>
> >> I stumbled across this when debugging a virtualbox-ose configure
> >> failure. The test executable was linked to the ports version of
> >> libssl.so but rtld chose the base libssl.so at run time.
> >
> > This is also the issue with ports-mgmt/pkg on a system that still
> > requires OpenSSL 1.0.2 from ports in order to support an old client.
> >
> > cwfw# pkg info
> > ld-elf.so.1: /usr/local/lib/libcrypto.so.9: version OPENSSL_1_1_0
> > required by /usr/local/lib/libpkg.so.4 not defined
> > cwfw#
> >
> > If I remove security/openssl, the above issue is resolved however the
> > old client, which should be replaced next year, fails to communicate
> > with the server. The classic rock & a hard place scenario.
>
> Not saying this is a real solution for the general problem, but can you use a
> libmap.conf entry to work around this?
I tried using the path1 path2 form. No joy there.
--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201810141236.w9ECaSHd007740>