LibreSSL infects ports, causes problems

[Baptiste Daroussin]

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 freebsd.org> 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:
http://people.freebsd.org/~bapt/nobase.mk
http://people.freebsd.org/~bapt/ssl.mk

which will make switch from USE_OPENSSL to USES=ssl
nobase.mk 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.

Best regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20150409/c55ce56a/attachment.sig>