LibreSSL infects ports, causes problems

Bryan Drewery bdrewery at
Thu Apr 9 16:26:00 UTC 2015

On 4/9/2015 11:14 AM, Baptiste Daroussin wrote:
> On Thu, Apr 09, 2015 at 04:00:45PM +0000, Loganaden Velvindron wrote:
>> On Thu, Apr 9, 2015 at 3:56 PM, Baptiste Daroussin <bapt at> wrote:
>>> On Thu, Apr 09, 2015 at 05:53:45PM +0200, Christian Weisgerber wrote:
>>>> Baptiste Daroussin:
>>>>> Some how you have mixed up things between base openssl and libressl, when
>>>>> starting to activate libressl if you are using ports only you have to be extra
>>>>> careful, (same goes with ncurses or ports openssl) just installing those ports
>>>>> is enough to "pollute" nearly anything you build after with a dependency on it
>>>>> (well anything that does link to libssl, libcrypto)
>>>> Well, yes, that's what I said.  It's a bug.
>>>>> If it very complicated and
>>>>> error prone to cherry pick "only take base openssl here, only ports openssl
>>>>> there" the only "safe" way to solve this situation and being consistent is to
>>>>> always skip the version from base and enforce the version for ports. (the
>>>>> otherway around is impossible - very complicated)
>>>> And the addition of LibreSSL as a not-quite-equivalent alternative
>>>> to ports OpenSSL makes this even more complicated.  You can expect
>>>> things coming out of OpenBSD (like new versions of net/openntpd)
>>>> to require LibreSSL, because it includes a new library libtls that
>>>> doesn't exist in OpenSSL.  In the meantime, LibreSSL has removed
>>>> some of the more horrific APIs of OpenSSL, which means some ports
>>>> will not build against LibreSSL as is.  Like python27.  Fixes for
>>>> these problems can be picked from the OpenBSD ports tree, if we
>>>> want to.
>>>> It's kind of hard to fix such problems if there is no clear policy
>>>> how things are supposed to work in the first place.
>>> I'm and other are working on a policy about that: always enforce openssl from
>>> ports with just a flag to say I want openssl or I want libressl but not both,
>>> would apply to others libs that behave the same way but I have limited time on
>>> this any one who wants to work on that is welcome :)
>> I think that we need to build up a team of people who are interested
>> in making that happen in FreeBSD.
>> I would be very interested to have a LibreSSL-powered FreeBSD server
>> for production use at work.
> The thing is when you start pulling the string on this then you have to handle
> all the other cases, because ports binaries will end up with some rpath to make
> sure it finds in priority things from localbase, but then if it is also linked
> to libarchive, ncurses, etc it will grab the localbase version as well
> (depending on the shlib version of those) so doing the job for one of the lib
> means doing it for all others.
> For now candidates are:
> libarchive
> ncurses
> readline (which will have then to be linked to ports ncurses and not base
> version through the magic of fake libtermcap)
> openssl
> libedit(?)
> for now I do have:
> which will make switch from USE_OPENSSL to USES=ssl
> is for ncurses basically USES=ncurses will die and ncurses will just
> become a regular LIB_DEPENDS
> When it becomes fun is that now all ports will have to really respect LDFLAGS...
> I already found a couple of bad boys in that area.
> btw that should also solve some issues with python and its ncurses module.

Peter has pointed out that OpenSSL has symbol versioning that we are not
using. Enabling this in base may help the conflict issue here. Even if
we force all ports to use ports OpenSSL we run into the problem you
describe of loading in the base OpenSSL when linking some libraries. The
versioning may avoid that. Of course that would only solve for
11.0/10.2/9.4 and not current releases.

Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <>

More information about the freebsd-ports mailing list