On 6/2/15 12:25 AM, Kimmo Paasiala wrote:
On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk <ka...@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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
_______________________________________________
freebsd-security@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
