Date: Tue, 02 Jun 2015 00:44:46 +0800 From: Julian Elischer <julian@freebsd.org> To: freebsd-security@freebsd.org Subject: Re: avoiding base openssl when building ports Message-ID: <556C8BFE.708@freebsd.org> In-Reply-To: <CA%2B7WWSc47cH_C%2BJCFNv22onuf-V=mFNQ%2BU96Gx_vUm-1YU2OdQ@mail.gmail.com> References: <201506010138.t511cp2P088983@gw.catspoiler.org> <alpine.GSO.1.10.1506011214350.22210@multics.mit.edu> <CA%2B7WWSc47cH_C%2BJCFNv22onuf-V=mFNQ%2BU96Gx_vUm-1YU2OdQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/2/15 12:25 AM, Kimmo Paasiala wrote: > On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk <kaduk@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-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?556C8BFE.708>