avoiding base openssl when building ports

[Julian Elischer]

On 6/2/15 12:25 AM, Kimmo Paasiala wrote:
> On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk <kaduk at mit.edu> wrote:
>> On Sun, 31 May 2015, Don Lewis wrote:
>>
>>> The big culprit turned out to be ftp/curl.  Even though
>>> WITH_OPENSSL_PORT=yes caused it to add the openssl port as a build and
>>> run dependency, it was silently getting linked to openssl from base. The
>>> cause of that problem is that the default GSSAPI_BASE option adds
>>> -L/usr/lib near the start of LDFLAGS, so the linker finds the base
>>> openssl libraries instead of the ones from the port.  I worked around
>>> that problem by switching to GSSAPI_NONE, though I tested that the other
>>> GSSAPI_* options also work correctly.  There is a sanity check in the
>>> Makefile that attempts to catch this conflict, but it does not work
>>> correctly.  See
>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200555>.
>> My apologies for semi-hijacking your thread, but I am starting to wonder
>> whether the base Heimdal (and GSSAPI) should be converted to be a private
>> library.  Since I am living in a MIT krb5 world, which is incompatible
>> with the Heimdal libraries, I end up having some trouble trying to force
>> various things to be used from base vs. ports.
>>
>> Making the Heimdal in base into private libraries would "solve" the
>> problem with ftp/curl, but only insamuch as it would make the GSSAPI_BASE
>> option useless and require a GSSAPI from ports.
>>
>> -Ben
>
> Rumour is that something like that is going to happen with all of the
> problematic libraries by making them private. If someone with inside
> knowledge could confirm these rumours? ;)
>
> This leads to another question. Where is the line going to be drawn
> which libraries in the base system should be private? There are
> certainly some of them that have to be public like libc and the
> support libraries like libusb. There is certainly no sense in making
> the ports system use full set of its own libraries for everything
> either.
I'd like to take a bunch of libraries out of base, But That is not the 
same as making them "ports".
I've said before that I thik we need something half way between. using 
the ports/pkg mechanism,
but from an administrative point of view, still a part of base..
Easier to upgrade, but yet, still considered part of the base 
distribution.
in other words, currently a failure in ncurses can stop a release from 
shipping, and
in my world a failure in "base pkg ncurses"  would still have that 
ability, but would
be delivered as a separately upgradable pkg.

i.e. some pkgs are more important than others.



>
> -Kimmo
> _______________________________________________
> freebsd-security at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-unsubscribe at freebsd.org"
>
>